Re: Parsing of pg_hba.conf and authentication inconsistencies
От | Magnus Hagander |
---|---|
Тема | Re: Parsing of pg_hba.conf and authentication inconsistencies |
Дата | |
Msg-id | 48A00174.8030703@hagander.net обсуждение исходный текст |
Ответ на | Re: Parsing of pg_hba.conf and authentication inconsistencies (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: Parsing of pg_hba.conf and authentication inconsistencies
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: