Subject: Re: group for access to the password database
To: matthew green <>
From: Steven M. Bellovin <>
List: tech-security
Date: 07/10/2000 13:40:09
  by with SMTP; 10 Jul 2000 17:41:50 -0000
	by (Postfix) with ESMTP
	id 6CFA91E043; Mon, 10 Jul 2000 13:41:44 -0400 (EDT)
	by (8.8.7/8.8.7) with ESMTP id NAA01924;
	Mon, 10 Jul 2000 13:40:30 -0400 (EDT)
	by (Postfix) with ESMTP
	id 0B9FF35DC2; Mon, 10 Jul 2000 13:40:23 -0400 (EDT)
From: "Steven M. Bellovin" <>
To: matthew green <>
Cc: (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: <>

In message <>, 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