From owner-freebsd-hackers Mon Nov 3 12:55:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA02834 for hackers-outgoing; Mon, 3 Nov 1997 12:55:31 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from gaia.coppe.ufrj.br (cisigw.coppe.ufrj.br [146.164.5.200]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA02818 for ; Mon, 3 Nov 1997 12:55:19 -0800 (PST) (envelope-from jonny@coppe.ufrj.br) Received: (from jonny@localhost) by gaia.coppe.ufrj.br (8.8.7/8.8.7) id SAA09155; Mon, 3 Nov 1997 18:52:51 -0200 (EDT) (envelope-from jonny) From: Joao Carlos Mendes Luis Message-Id: <199711032052.SAA09155@gaia.coppe.ufrj.br> Subject: Re: Password verification (Was: cvs commit: ports/x11/kdebase - Imported sources) In-Reply-To: <199711031452.JAA24127@skynet.ctr.columbia.edu> from Bill Paul at "Nov 3, 97 09:52:37 am" To: wpaul@skynet.ctr.columbia.edu (Bill Paul) Date: Mon, 3 Nov 1997 18:52:51 -0200 (EDT) Cc: perhaps@yes.no, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk #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