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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg_restore --clean vs. large object
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [PATCH] user mapping extension to pg_ident.conf