Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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:
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 

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 

Hope this clarifies a bit.

Lars Kanis

In response to


pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group