Re: Status of my submissions

[Torsten Duwe <duwe@caldera.de>]

    Joel> shadow is now fully PAM-enabled thanks to its present Debian
    Joel> maintainer (the only reason upstream doesn't have the patches
    Joel> merged is because Marek hasn't had time to make a new release yet).

[Just joining the discussion I assume you're talking about Marek
Michaelcievic's (sp?) "shadow"-package ?]

    Joel> [ Later, it's clarified that you meant "pwdb" instead of "passwddb"
    Joel> ] pwdb is a bad idea for a couple of reasons, first of all it
    Joel> duplicates the functionality of NSS, a mechanism which works fine
    Joel> and does not need to be bypassed. Second, pam_unix does everything
    Joel> pam_pwdb does without bypassing NSS.

The main reason for libpwdb was that there had been no way of determining
which database a getpw*() value came from. This is in fact irrelevant, and
duplicating the code was futile (:-) iff you're only interested in read-only
access to the "password" database. However if you're up to changing fields in
"the database", knowledge about the fields' origin is required. Hence libpwdb.

Looking at Linux-PAM-0.72/modules/pam_unix/pam_unix_passwd.c, the one and
only (?) file that needs to make such changes, I come up with the following
counter-example. It may sound a little bit artificial, but it's nevertheless
realistic and should serve the purpose of demonstrating pam_unix'
deficiencies when compared to pam_pwdb:

"
Assume I have a laptop, which I use at home, when travelling, at work, at the
university, etc. Of course I keep my own account locally in /etc/passwd. At
work / univerity / ... I want my colleagues to be able to log in and so I
start NIS. Surely I have a NIS account, too.

Now I want to change my local laptop password. I use a PAMified "passwd"
program that's configured for pam_unix use, as you propose. That one will
getpwent() the local entry, will then ask the NIS master and authenticate
using the local entry --> BAD.

libpwdb will do the equivalent of getpwent() and will record where it got the
entry from (the local /etc/passwd in this case). Further updates will go
there.
"

This is what libpwdb was designed for, and it shouldn't be simply dropped for 
something less perfect. I'd vote for integrating pam_unix, pam_pwdb and
libpwdb into something that works correctly with minimal code duplication.

Just my 2 (Euro:-) cents,

	Torsten

--
Torsten Duwe
Senior Developer
duwe@caldera.de