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

Re: Missing prompt item in PAM



Andrew Morgan writes:
>       pam_putenv(pamh, "PAM_PASSWORD_PROMPT=reveal your secret: ");
>       pam_authenticate();
>       pam_putenv(pamh, "PAM_PASSWORD_PROMPT");     /* gone */
>
>Can you give an example?

Oh, I'm just paranoid that whatever environment variable name we
choose, someone else will be using and depending on it, but you
are right that PAM_PASSWORD_PROMPT is not likely to be set.  I'm
just paranoid in a different way from you.  Everything I can say
about the PAM_PASSWORD_PROMPT environment variable you could say
about a PAM_PASSWORD_PROMPT pam_item.

But
	save = pam_getenv(pamh, "PAM_PASSWORD_PROMPT")
	pam_putenv(pamh, "PAM_PASSWORD_PROMPT=reveal your secret: ");
	pam_authenticate();
	snprintf(savevar, n, "PAM_PASSWORD_PROMPT%s%s", save ? "=" : "", save);
	pam_putenv(pamh, savevar);
would preserve any previous setting and answer my paranoia.

>It requires adding code to libpam that is not useful for much beyond
>pam_unix.so.

And every other module that asks for passwords...

>It encourages application developers to think that libpam
>has something to do with passwords.

It's a HINT to modules.  If you think that application developers
think that PAM has nothing to do with passwords, you haven't been
talking to very many application developers!  It's a HINT.  A HINT
that would be ignored when appropriate.

If you'd rather have a more general hint that says "Expose user
name data while requesting authentication information", that's
fine with me.  Would that make sense to you?

I'm just sick and tired of having people complain to me over and
over again that they don't know what password to enter, and you
know, they are right.  We are coming up against a wall when we
try to take advantage of PAM's flexibility.  I want to fix that...

>Its incompatible with other implementations of PAM.

We've already extended libpam, and I thought you were talking to
Sun about desired changes.  Did I misunderstand?

>> 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.

Well, it doesn't require that modules follow a as-yet-unspecified
protocol that third-party modules won't follow for a bit yet and
so when they customize their install it will suddenly fail to work...
It is at least minimally robust, as ugly as it is.  For now, I have
something that *works*.  It *is* disgusting, but it is relatively
robust.

I'm not saying that a hint token would not have the same effect, it
just wouldn't be as ugly.  :-)

michaelkjohnson

"Magazines all too frequently lead to books and should be regarded by the
 prudent as the heavy petting of literature."            -- Fran Lebowitz
 Linux Application Development     http://people.redhat.com/johnsonm/lad/



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