Date: Tue, 04 Nov 1997 12:10:49 +1030 From: Mike Smith <mike@smith.net.au> To: Bill Paul <wpaul@skynet.ctr.columbia.edu> Cc: perhaps@yes.no (Eivind Eklund), hackers@freebsd.org Subject: Re: Password verification (Was: cvs commit: ports/x11/kdebase - Imported sources) Message-ID: <199711040140.MAA00528@word.smith.net.au> In-Reply-To: Your message of "Mon, 03 Nov 1997 09:52:37 CDT." <199711031452.JAA24127@skynet.ctr.columbia.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> > The SCM_CREDS hack will work better. For those who don't know, SCM_CREDS > is an additional type of ancillary data that you can transmit with > sendmsg()/recvmsg() via an AF_UNIX socket. It's similar to SCM_RIGHTS [... description ...] This beats the living crap out of the whole PAM approach. 8) > Now, all that aside, you could use the SCM_CREDS hack and AF_UNIX sockets > to create a 'password database access' daemon and fix it so that a user > can see his own encrypted password and noone else's. But consider the > following: > > - If the system uses this daemon for login authentication and the daemon > crashes, noone will be able to log in. The API that user processes use should support local passwords as a fallback in this event. > - Consider getpwent(3). You have to make the daemon be able to handle > things like enumerating the passwd database, not just retrieving > arbitrary records. If you support stacking based on the source of the request, enumerating all of the users that may be permitted on the system actually becomes pretty pointless. In some cases, it may actually not be possible to traverse the list of users (consider using something like Radius for remote user authentication). What applications actually require the ability to enumerate all users on a system? mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711040140.MAA00528>