Re: [PATCH] user mapping extension to pg_ident.conf
От | Magnus Hagander |
---|---|
Тема | Re: [PATCH] user mapping extension to pg_ident.conf |
Дата | |
Msg-id | 9837222c0907210650h68f11f3dlbb5c246b1e93969c@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] user mapping extension to pg_ident.conf (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: [PATCH] user mapping extension to pg_ident.conf
(Tom Lane <tgl@sss.pgh.pa.us>)
|
Список | 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@snowman.net> wrote: > * Lars Kanis (kanis@comcard.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 MSSQL. 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 differ. 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. -- Magnus HaganderSelf: http://www.hagander.net/Work: http://www.redpill-linpro.com/
В списке pgsql-hackers по дате отправления: