Subject: Re: group for access to the password database
To: matthew green <>
From: James Chacon <>
List: tech-security
Date: 07/10/2000 14:52:10
  by with SMTP; 10 Jul 2000 18:52:12 -0000
	by (8.9.3/8.9.3) with ESMTP id OAA17750;
	Mon, 10 Jul 2000 14:52:11 -0400 (EDT)
From: James Chacon <>
	by (8.9.0/8.9.0) id OAA07589;
	Mon, 10 Jul 2000 14:52:10 -0400 (EDT)
Message-Id: <>
Subject: Re: group for access to the password database
To: (matthew green)
Date: Mon, 10 Jul 2000 14:52:10 -0400 (EDT)
Cc: (Steven M. Bellovin), (NetBSD Security Technical Discussion List)
In-Reply-To: <> from "matthew green" at Jul 11, 2000 03:32:51 AM
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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

Now you're sounding suspicously like a door call (ala Solaris).