On Wed, Jan 31, 2001 at 02:02:02PM -0500, Ben Collins wrote:
> That's the most ignorant statement I have seen in awhile. So you suggest
> that a desktop box with one account have Kerberos or LDAP for users?
Come on. We have been talking about networked machines offering
services to the outside, right?
> Your statement has nothing to do with the point at hand. Obviously if
> you always use krb or ldap, then why should you even care about the
> pam_unix.so module anyway?
OK, please accept my apologies for not elaborating the point.
My opinion is that the /etc/shadow approach has problems that are
routinely ignored, unfortunately. Just consider the case on hand: Any
daemon has to be root to be able to use it. Now we all know that
daemons running as root are a big risk, so a password database that
doesn't have that requirement while still not allowing anyone to
*read* crypted passwords (as opposed to *checking* them) would be an
Additionally, the benefits shadow has are overrated in my opinion, not
because the approach is generally flawed but because many programs
using it don't place the same emphasis on security that an
authentication system does. It places a burden on the daemon software
to behave correctly (e.g., enforce fail delays) and many don't. An
authentication service that concentrates that behaviour would be an
improvement. PAM does that through a library, which makes for a
Last, but not least, its impossible to implement a challenge-response
based authentication system on top of shadow. Again, this is not the
fault of shadow, it was inherited from passwd, but its a point to keep
in mind. The "security" of a password database where users must send
their passwords in the clear (or if not, at least readable to the
server, which can be just as bad) is a matter of big concern for me.
Now, all this doesn't mean that shadow is not usefull. Especially in
the case you quoted (desktop machines not permanently connected to a
network), it has a place. However, in general, I think shadow offers a
false sense of security and better solutions should be sought.
> No, it's not the same. The program runs quickly and does nothing but
> auth the user and return an exit value. It is not tied down by PAM or
> any other policies (such as delay on failure, etc.). It never going to
> be able to auth any user other than the egid of the calling process.
Thats an implementation issue. Nothing in the concept would prevent
the helper from imposing a fail delay. For example, it could do so
automatically whenever its not authenticating the RUID its running
under and leave it to the library in the other cases. This would not
be a problem at all, in my opinion.