Re: PAM authentication fails for local UNIX users
От | Jeroen T. Vermeulen |
---|---|
Тема | Re: PAM authentication fails for local UNIX users |
Дата | |
Msg-id | 5338.125.24.242.1.1187618022.squirrel@webmail.xs4all.nl обсуждение исходный текст |
Ответ на | Re: PAM authentication fails for local UNIX users (Andrew Dunstan <andrew@dunslane.net>) |
Список | pgsql-hackers |
On Mon, August 20, 2007 19:52, Andrew Dunstan wrote: > I'd rather see an HBA fallback mechanism, which I suspect might overcome > most of the problems being encountered here. I implemented a form of that once, so on local connections you could do ident mapping with fallback to PAM or some other password authentication. That seemed useful, e.g. for granting non-interactive access to a program running under a dedicated user and requiring a password from everyone else. The implementation also allowed for a bit more flexibility in the auth mechanism. The main objections I recall were: 1. The protocol doesn't allow for multiple authentication prompts. My own proposal didn't have that problem since it only introduced an "optional ident" authentication that continued looking for a matching rule if the current user name was not in the given map, but it's a problem for more general approaches. 2. For real, fully generalized fallback, you'd also need to overhaul the HBA config file format completely. 3. It was considered unsafe to add even the most limited of fallback options, because the HBA config is designed to pick just one auth mechanism for any connection attempt, based on only the first three columns of the config file. An admin who didn't understand the new auth mechanism could use it to write an unsafe HBA configuration, provided it also broke the existing "go from specific-permissive to general-restrictive" design guideline. Personally I think it'd take some careful aim to shoot yourself in the foot like that, but IIRC it was enough for an "I don't like it" vote. Jeroen
В списке pgsql-hackers по дате отправления: