Monday, August 11, 2008

Re: [HACKERS] Parsing of pg_hba.conf and authentication inconsistencies

Stephen Frost wrote:
> Magnus,
>
> * Magnus Hagander (magnus@hagander.net) wrote:
>> Yeah. I think the question there is just - how likely is it that the
>> same installation actually uses >1 authentication method. Personally, I
>> think it's not very uncommon at all, but fact remains that as long as
>> you only use one of them at a time, using a shared file doesn't matter.
>
> We use multiple authentication types *alot*.. ident, md5, kerberos, and
> gssapi are all currently in use on our systems. ident for local unix
> logins, md5 for 'role' accounts and software the doesn't understand
> kerberos, kerberos/gssapi depending on the age of the client library
> connecting. Oh, and we use pam too.. We use some mappings now with
> ident, which I'd expect to continue to do, and I've got definite plans
> for mappings under Kerberos/GSSAPI once it's supported..

Ok. Good to know - if you want to use it, there are bound to be a number
of others who would like it as well :)


>>> It wouldn't be very easy/clean to do that w/o breaking the existing
>>> structure of pg_ident though, which makes me feel like using seperate
>>> files is probably the way to go.
>> Yeah, thats my feeling as well. Now, can someone figure out a way to do
>> that without parsing the file in the postmaster? (And if we do parse it,
>> there's no point in not storing the parsed version, IMHO). And if not,
>> the question it comes down to is which is most important - keeping the
>> parsing away, or being able to do this ;-)
>
> I don't have an answer wrt the parsing issue, but I definitely want to
> be able to do this. :)

Right.

I guess one option would be to load the map file at runtime in the
backend, and not pre-load/cache it from the postmaster. But that seems
rahter sub-optimal to me. Other thoughts?

//Magnus

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

No comments: