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

Re: PAM concepts (was: pam_{unix,pwdb}: crypt/md5 necessary?)

On Thu, Aug 03, 2000 at 06:47:32PM +0400, Michael Tokarev wrote:
> pam_{unix,pwdb} modules.  Some questions was popped up when I liiked to
> them closely and remember a history.  The simplest question is --
> Why two of them with more-or-less similar functionality?  Unixes
> now have some sort of nsswitch -- so -- why the pwdb just comes in
> not utilizing the features of plain getpwnam() & Co!?

Calm down.  At the time pwdb was written, the nsswitch subsystem in
Linux's libc was not nearly as mature as it is today.  Now that it is,
pwdb is being phased out.

> Okay, let's see pam_unix.  It uses generic getpwnam/getspnam interface,
> and it have no knowledge about actual source of information this routines
> returns (this stated in comments there).  So -- and this is conceptual
> question -- why it should deal with password stack at all?  It will be
> unusable if nsswitch will point to ldap for example...

Patches have floated around on this mailing list that make pam_unix check
on these things before it bothers doing a password-change operation.  If
it fails, a properly configured stack will continue on to try pam_ldap,
with the end-user none the wiser.

OTOH, it's quite possible that a pam_files module (akin to nss_files)
would be very useful; it would need at least a companion pam_nis to be a
complete replacement for pam_unix's password-changing module.

> Ok, let's see next thing.  Asking new password.  Why pam_unix, pam_pwdb
> attempted to ask new password in their passwd routines?  Why in this
> case pam_cracklib?  Remember the previous statement -- many little
> "storing" modules? -- in this respect, there should be definitely one
> "asking" module like cracklib, and "storing" modules should just store
> PAM_AUTHTOK, not asking one...  Cracklib does a good job in enshuring
> password quality, and there is no need to duplicate this many times.

Most password management modules understand a "use_authtok" flag for just
this reason.  Interoperability between PAM modules is always tricky if
you don't want to introduce dependencies where none existed before.
> Again, "password asking".  One good thing that can do pam_unix is to
> enshure that new password is not the same as one of previous ones
> (remember=XXX).  Really good thing.  But -- where those old passwords
> should be stored?  This is not a trivial question. All are ok while
> your usere are on only one machine, -- /etc/security/opasswd is good.
> But if you have network with nis/ldap/etc, and user can change password
> on any machine?  What one should do when account should be deleted?

If you're using a networked authentication system, then this is policy,
and as such I really think it should belong on the server.  This means
it is not PAM's problem to solve.


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