Subject: Re: group for access to the password database
To: NetBSD Security Technical Discussion List <>
From: Steven M. Bellovin <>
List: tech-security
Date: 07/10/2000 11:00:51
  by with SMTP; 10 Jul 2000 15:01:19 -0000
	by (Postfix) with ESMTP id D36DD1E00F
	for <>; Mon, 10 Jul 2000 11:01:16 -0400 (EDT)
	by (8.8.7/8.8.7) with ESMTP id LAA28277
	for <>; Mon, 10 Jul 2000 11:01:12 -0400 (EDT)
	by (Postfix) with ESMTP id 741C835DC2
	for <>; Mon, 10 Jul 2000 11:01:01 -0400 (EDT)
From: "Steven M. Bellovin" <>
To: (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 11:00:51 -0400
Message-Id: <>

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

		--Steve Bellovin