On 16-10-2015 10:37, Robert Haas wrote:
- Did he implement this correctly?
>
- Would it break anything?
>
I did not review the patch.
- Are there lots of other knobs we should expose too instead of just one?
>
We are providing PAM_USER and PAM_CONV. The complete list of options are
[1]. Maybe PAM_RUSER? BTW, we could use pg_ident.conf to map user foo
(app) to user bar (PAM).
- What would it take to turn this into a committable patch?
>
Review?
- Would the cost of exposing this and perhaps some other knobs cost
too much in performance for the number of people it would make happy?
>
No.
- If so, should the behavior be GUC-controlled or is there
justification for arguing we should drop the whole patch?
The patch always set PAM_RHOST, ie. it means I can't disable it (at the
postgres side). Is it a problem? Of course the PAM module can provide a
way to ignore it but it is not our business.
I feel like we've got somebody new showing up to our community with an
idea that is not obviously stupid. If we want such people to stick
around, we should try to give their ideas a fair shake.
I share the same feeling. I wasn't trying to throw a cold water on it.
[1] http://pubs.opengroup.org/onlinepubs/8329799/pam_set_item.htm
--
Euler Taveira Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
