NSS and PAM

[Julian Elischer]

On Thu, 4 Dec 2003, Robert Watson wrote:

>=20
> On Fri, 5 Dec 2003, Dag-Erling Sm=F8rgrav wrote:
>=20
> > Jacques Vidrine <nectar at freebsd.org> writes:
> > > Applications that use PAM to change the password when the password
> > > expires seem to work out OK.
> >=20
> > This works because each backend knows whether or not the password needs
> > changing (there is a flag to tell the module to only ask for a new
> > password if the current password has expired).  When you are purposedly
> > changing your password before it expires, things are a little less
> > clear.=20
> >=20
> > Things might be easier if NSS had a proper API which included entry
> > points for storing and updating user information (and not just for
> > retrieving).  Then pam_unix wouldn't need to know anything about
> > /etc/spwd.db or NIS; it would just retrieve the information from NSS,
> > note that the password had expired, ask the user for a new password and
> > tell NSS to store it.
>=20
> I think I agree pretty strongly with your earlier comment that the curren=
t
> "struct passwd" is simply insufficient for a lot of the things we'd like
> to accomplish.  It's good for UNIX app compatibility and home directory
> expansion, but it sounds like we need a much stronger notion of "user"=20
> than we currently have.  We bump into this in the existing of login.conf,
> setusercontext(), and the MAC code.  It might be worth digging into
> Apple's DirectoryServices, as well as Solaris's roles/etc equivilent.

We also desperatly need an interface for opaquely WRITING a password
entry into NIS or flatfile or whatever.
porting npasswd to freeBSD was a pain in the neck because of this..

Npasswd has a "mpasswd" struct that includes the system's
passwd structure but contains a 'per method' pointer and fileds for=20
password expiration etc. as well. The interface needs to also
automatically do things like load the login.conf info for the user and
the auth.conf info as well.

I had to do that all by hand in the npasswd port which was a real
annoyance.


>=20
> Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
> robert at fledge.watson.org      Senior Research Scientist, McAfee Research
>=20
>=20
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org=
"
>=20