Date: Mon, 3 Nov 1997 18:52:51 -0200 (EDT) From: Joao Carlos Mendes Luis <jonny@coppe.ufrj.br> To: wpaul@skynet.ctr.columbia.edu (Bill Paul) Cc: perhaps@yes.no, hackers@FreeBSD.ORG Subject: Re: Password verification (Was: cvs commit: ports/x11/kdebase - Imported sources) Message-ID: <199711032052.SAA09155@gaia.coppe.ufrj.br> In-Reply-To: <199711031452.JAA24127@skynet.ctr.columbia.edu> from Bill Paul at "Nov 3, 97 09:52:37 am"
next in thread | previous in thread | raw e-mail | index | archive | help
#define quoting(Bill Paul) // Of all the gin joints in all the towns in all the world, Eivind Eklund // had to walk into mine and say: // // > > On Sun, 2 Nov 1997, Joao Carlos Mendes Luis wrote: // > > ... // > > > But, how to allow users check only their own password, and still // > > > have the added security of shadow passwords ? I can only think // > > > in a kind of password checking daemon that would accept commands // > > > on a AF_UNIX socket and some patches to libc pw commands. // > > // > > You can always use the pwcheck daemon from the Cyrus module (see ports). // > > It opens a unix socket at /var/pwcheck/pwcheck. Permissions on the // > > /var/pwcheck directory can be used to determine who can check passwords. ... // 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 // which, in 4.4BSD, is used to transfer a file descriptor between processes. // The idea is that the calling process does a sendmsg() with the SCM_CREDS // flag set and an empty controll emssage buffer, and when the kernel sees // this in unp_internalize(), it fills in the empty buffer with the sending // process's credentials (UID, EUID, GID, other GIDS). When the receiving // process does a recvmsg(), it gets a copy of the filled-in buffer and // can use the credential info to determine the identity of the sending // process and do access checks. If the sender does not set the SCM_CREDS flag // when it transmits, the receiver can tell and refuse to do business with // the sender. Humm... This needs some change from the sender point of view, right ? Maybe it could be more useful if it messed only with the receiver side. Is it possible ? Probably not, for datagram stuff. // 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. I thought about that. Just make the program use this as an option, and not the default behavior. Maybe, even, not automatic. // - You have to code it in such a way that it won't fall apart in the face // of heavy (and possibly concurrent) access by clients. Sure. To make a head start, maybe a very simple forking connection daemon could work. Multithreading is always an option, of course. // - Consider getpwent(3). You have to make the daemon be able to handle // things like enumerating the passwd database, not just retrieving // arbitrary records. Could you please elaborate on this ? // This is starting to sound suspiciously like ypserv(8). Like every server daemon... I just thought about inetd. Do we have something similar for AF_UNIX sockets ? I have a question. What's the better approach for this ? A /etc/master.passwd window daemon, which allows users to read their own record, or just a username/password verify daemon ? In the first case, it can be embedded in libc and apps will not notice the difference. "Hey, why all passwords are '*' except mine ?" In the second case, apps should be modified, but it also allows for other kinds of auth systems. (Argh, this stinks like PAM). Jonny -- Joao Carlos Mendes Luis jonny@gta.ufrj.br +55 21 290-4698 jonny@coppe.ufrj.br Universidade Federal do Rio de Janeiro UFRJ/COPPE/CISI PGP fingerprint: 29 C0 50 B9 B6 3E 58 F2 83 5F E3 26 BF 0F EA 67
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711032052.SAA09155>