Subject: re: group for access to the password database
To: Steven M. Bellovin <>
From: matthew green <>
List: tech-security
Date: 07/11/2000 03:32:51
  by with SMTP; 10 Jul 2000 17:32:54 -0000
	by (Postfix) with ESMTP
	id 646D42651; Tue, 11 Jul 2000 03:08:01 +1000 (EST)
To: "Steven M. Bellovin" <>
Cc: (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."
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: <>
From: matthew green <>

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