From owner-freebsd-hackers  Mon Nov  3 17:45:13 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id RAA23151
          for hackers-outgoing; Mon, 3 Nov 1997 17:45:13 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA23145
          for <hackers@freebsd.org>; Mon, 3 Nov 1997 17:45:07 -0800 (PST)
          (envelope-from mike@word.smith.net.au)
Received: from word.smith.net.au (localhost.gsoft.com.au [127.0.0.1])
	by word.smith.net.au (8.8.7/8.8.5) with ESMTP id MAA00528;
	Tue, 4 Nov 1997 12:10:49 +1030 (CST)
Message-Id: <199711040140.MAA00528@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
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) 
In-reply-to: Your message of "Mon, 03 Nov 1997 09:52:37 CDT."
             <199711031452.JAA24127@skynet.ctr.columbia.edu> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 04 Nov 1997 12:10:49 +1030
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> 
> 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