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:
>> # MAPNAME SYSTEM-USERNAME PG-USERNAME
>> 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.
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2009-07-21 13:58:05|
|Subject: Re: [PATCH] user mapping extension to pg_ident.conf |
|Previous:||From: Alexey Klyukin||Date: 2009-07-21 13:47:47|
|Subject: errcontext support in PL/Perl|