Re: [PATCH] user mapping extension to pg_ident.conf

From: Lars Kanis <kanis(at)comcard(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org, Magnus Hagander <magnus(at)hagander(dot)net>
Subject: Re: [PATCH] user mapping extension to pg_ident.conf
Date: 2009-06-29 16:05:20
Message-ID: 200906291805.24678.kanis@comcard.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Am Montag, 29. Juni 2009 16:26:56 schrieben Sie:
> Lars Kanis <kanis(at)comcard(dot)de> writes:
> > this patch adds the possibility to map the login-rolename to a different
> > rolename actually used for permissions.
>
> This seems like an ugly addition with a very narrow use case. Can't
> you accomplish what you want with the existing usermap facility?

You're right, my description is a bit incomplete.

The problem I have, is that I want to use an ordinary windows application,
which connects to an arbitrary ODBC data source. This application stores a
fixed username und password for the connection within it's own binary data
file. It doesn't know anything about TLS-connection nor smartcard based
authentication. All this is done in the libpg.dll.

It works fine so far, as long as I want to work with the sigle role given by
the fixed username. I could map any cn-contents to this one user by writing:
# MAPNAME SYSTEM-USERNAME PG-USERNAME
ssl-user /.* fixed_user

The db internal role is always that given by the application. But I need to
work with the role of the certificate-cn of the current smartcard, the
application doesn't know about. Because the username is stored within the
applications own binary data file I'm not able to change it according to the
pluged in card.

I think the same problem occurs with kerberos authentication. You can't get
the role based on your kerberos ticket, when the username is not set
likewise.

So it seemed to me quite useful, to not just set which external name matches
which login-username, but also to set which userrole is actually used for
granted privilegs. This is done by an additional column with the same
characteristic as column PG-USERNAME.

Another way could be to add an parameter to the hba line which tells the
server to not care about the login username, but to only use the external
(CN) name. But this wouldn't have the flexibility of regexps like in
pg_ident.conf.

Hope this clarifies a bit.

regards
Lars Kanis

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-06-29 16:12:13 Re: [PATCH] user mapping extension to pg_ident.conf
Previous Message m_lists 2009-06-29 15:15:16 Re: Query progress indication - an implementation