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

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

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Lars Kanis <kanis(at)comcard(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] user mapping extension to pg_ident.conf
Date: 2009-07-21 13:50:58
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Sorry for jumping late into this discussion, but I've been out sailing
for a couple of weeks and stayed away from email :-)

On Mon, Jun 29, 2009 at 21:01, Stephen Frost<sfrost(at)snowman(dot)net> wrote:

> * Lars Kanis (kanis(at)comcard(dot)de) wrote:
>> 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.
> To be honest, I think the problem as described above makes it a no-go.
> What you're asking for is essentially "I want the server to ignore the
> username passed in" which just doesn't make sense.  It's unfortunate
> that this Windows application using ODBC doesn't allow for the username
> to be changed, but that's not something PG is going to solve for you.  I
> would recommend you work on fixing the application.

I think it's a reasonable expectation for there to be a way to pick up
the username from an external authentication system, such as Kerberos,
SSPI or certificate. Other databases that support them do - at least

That said, if there is a username specified it should not be ignored.
But if there is none specified, it should work. This works "reasonably
well" today, in that we pick the username up from the environment. But
I can see cases where it would be a lot more useful to have it instead
pick up the username from the authentication system, since they may

But in no case should this override what the user put in to the system
- but it could change the default.

>> 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
> What you really want is:
> ssl-user      user1_cn     user1
> ssl-user      user2_cn     user2
> ssl-user      user3_cn     user3
> or so..

Well, you'd write that too with a regexp map with a back reference.
That's the original reason I implemented regexps for pg_ident :-)

> And then have your application accept and use a username provided to it
> when connecting to ODBC.  Having your application pass some hard-coded
> username to PG all the time just isn't going to work.

I think the issue is "provided to it". There should be no need for the
user to know his username since he's already logged in.

I agree that the hard-coded-username method is broken.

 Magnus Hagander

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2009-07-21 13:58:05
Subject: Re: [PATCH] user mapping extension to pg_ident.conf
Previous:From: Alexey KlyukinDate: 2009-07-21 13:47:47
Subject: errcontext support in PL/Perl

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