[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Missing prompt item in PAM

"Michael K. Johnson" wrote:
> If environment variables are sufficient, why have pam_item's at all?
> This is strongly parallel to PAM_USER_PROMPT.  Why make it go through
> another channel?

libpam knows about users, it does not know about passwords.
> If you insist on making it go through an environment variable, it
> *still* should be set as a policy item in the Linux-PAM documentation

Absolutely. I'm in total agreement with this.

> precisely how it is to be interpreted.  Using an environment variable
> encourages environment pollution/destruction as well.  Using a pam_item
> instead keeps the information contained where it belongs.

An assertion I disagree with.

> I think that refusing to create PAM_PASSWORD_PROMPT is encouraging
> hackish workarounds.  Mangling conversation function data is a hack.
> Setting environment variables without regard to child processes
> (who knows what other use any particular environment string will
> have, and what data we will wipe out?) is hackish.  Creating

       pam_putenv(pamh, "PAM_PASSWORD_PROMPT=reveal your secret: ");
       pam_putenv(pamh, "PAM_PASSWORD_PROMPT");     /* gone */

Can you give an example?

> PAM_PASSWORD_PROMPT is clean, easy to specify, will not collide
> with anything else.  Why are you so set against it?

It requires adding code to libpam that is not useful for much beyond
pam_unix.so. It encourages application developers to think that libpam
has something to do with passwords. Its incompatible with other
implementations of PAM.

> hack is highly uninteresting.  By contrast, doing it cleanly is
> interesting, at least to me.

If you think using an environment variable is as ugly as hacking the
conversation function, I'm not likely to convince you.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []