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

Re: Missing prompt item in PAM

Michael K. Johnson wrote:
> 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...

The problem is that the application doesn't know which password is being
asked for. SAMBA, UNIX, homebrew, ...?

The application doesn't even know which user's password is being asked
for. One of the things a SCO developer is doing is really crazy but has
some parallels to the pam_if module that was announced a while back. He
has a 'mapping' auth module that from within the module, calls pam_start
to get a personal, local pamh (the module supplies a 'write-through'
conversation function which eventually propagates back to the
application and the user), but the whole authentication process takes
place with respect to a 'mapped' user account, without the application
ever knowing. Its all pretty cute/sick, but fits within our existing
implementations, and with a general (agnostic) application 'just works'.

The right place for the denominiation of the password to be announced
really is on the module stack. After all, its the thing that knows this
is a password and not some other random string, or whatever. Adding some
flexibility to the module to compose such a prompt makes more sense to
me. One could even have a pretty_password.so module, that takes an
argument containing a prompt format and fills in the blanks (%U etc.)
with PAM_USER etc., prompts the user for a password and fills in
PAM_AUTHTOK for the next module in the stack to actually use.
(pam_cracklib does this flavor of proxy for updating passwords -
although it's not quite as customizable as you want.)

My objection to PAM_PASSWORD_PROMPT in both forms (including a pam
environment variable), is that it encourages application developers to
believe they have influence over some aspect of the authentication
process, when I believe the influence should be in the hands of the

However, modules have access to and may respond to external
environmental conditions, so however strongly I feel, its currently
possible to use an environment variable for this. I'd guess it would
even be possible to use the existing module, pam_env.so, to set a
password prompt without adding any code to the application.

I'm not sure how the case where the admin arranges that you are asked
for two passwords, UNIX and then SAMBA will look. I'm pretty sure you
can manage this with environment variables from the stack:

 UNIX password for morgan:
 SAMBA password for SMORGAN:

but the application does not have enough granularity to do it easily:

 Password for morgan: 
 Password for morgan:

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

I am.

So far they have some definite interest in the
PAM_CONV_AGAIN/PAM_INCOMPLETE thing (I need to write it up), and they
are also curious about the binary prompt stuff, although the overhead
with that in terms of modifying libpam is basically zero -- one #define
in the equivalent of their _pam_types.h file.

That's the give, the take is that we adopt a stance with respect to the
'wakeup event' stuff/contribute to its design. Sun have basically
committed to needing this feature (they have 'a horrible undocumented
hack' in the field that they want to have corrected in their next
revision of PAM). The Biometric/peripheral people are also excited by
PAM (it provides a marketing hook for them to an established application
base) from their perspective 'wakeup event' things are crucial.

[I digress -- there is another thread for this discussion.]



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