by mail.netbsd.org with SMTP; 10 Jul 2000 17:41:50 -0000
	by mail-green.research.att.com (Postfix) with ESMTP
	id 6CFA91E043; Mon, 10 Jul 2000 13:41:44 -0400 (EDT)
	by postal.research.att.com (8.8.7/8.8.7) with ESMTP id NAA01924;
	Mon, 10 Jul 2000 13:40:30 -0400 (EDT)
	by smb.research.att.com (Postfix) with ESMTP
	id 0B9FF35DC2; Mon, 10 Jul 2000 13:40:23 -0400 (EDT)
From: "Steven M. Bellovin" <smb@research.att.com>
To: matthew green <mrg@eterna.com.au>
Cc: tech-security@netbsd.org (NetBSD Security Technical Discussion List)
Subject: Re: group for access to the password database 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 10 Jul 2000 13:40:09 -0400
Message-Id: <20000710174023.0B9FF35DC2@smb.research.att.com>

In message <29928.963250371@eterna.com.au>, matthew green writes:
>
>   *If* xlock should use the login password -- a concept which I'm dubious 
>   about -- the proper solution is a mechanism to permit applications to 
>   verify the password for their own UID only.  This might, for example, 
>   be by invoking a small, simple, setuid program that would read a 
>   candidate password on stdin and reply Y or N on stdout.  But limits the 
>   exposure of the shadow passwords to just the owner's, and it's likely 
>   to be a much simpler program than, say, xlock et al.  (And if you want 
>   to restrict even that ability to a few programs, make them setgid to 
>   group 'passwordcheck', and make my suggested program executable only by 
>   that group.)
>
>
>... or a little daemon you talk to over a unix socket with creditials,
>that way there is no set*id program at all.
>
That's a less-portable solution.  NetBSD is in better shape if it 
doesn't have to worry about maintaing a patch to xlock et al. for the 
indefinite future.

		--Steve Bellovin