by mail.netbsd.org with SMTP; 10 Jul 2000 17:32:54 -0000
	by splode.eterna.com.au (Postfix) with ESMTP
	id 646D42651; Tue, 11 Jul 2000 03:08:01 +1000 (EST)
To: "Steven M. Bellovin" <smb@research.att.com>
Cc: tech-security@netbsd.org (NetBSD Security Technical Discussion List)
subject: re: group for access to the password database 
in-reply-to: your message of "Mon, 10 Jul 2000 11:00:51 -0400."
             <20000710150101.741C835DC2@smb.research.att.com> 
organisation: people's front against (bozotic) www (softwar foundation)
x-other-organisation: The NetBSD Foundation.
Date: Tue, 11 Jul 2000 03:32:51 +1000
Message-ID: <29928.963250371@eterna.com.au>
From: matthew green <mrg@eterna.com.au>


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