by mail.netbsd.org with SMTP; 10 Jul 2000 15:01:19 -0000
	by mail-green.research.att.com (Postfix) with ESMTP id D36DD1E00F
	for <tech-security@netbsd.org>; Mon, 10 Jul 2000 11:01:16 -0400 (EDT)
	by postal.research.att.com (8.8.7/8.8.7) with ESMTP id LAA28277
	for <tech-security@netbsd.org>; Mon, 10 Jul 2000 11:01:12 -0400 (EDT)
	by smb.research.att.com (Postfix) with ESMTP id 741C835DC2
	for <tech-security@netbsd.org>; Mon, 10 Jul 2000 11:01:01 -0400 (EDT)
From: "Steven M. Bellovin" <smb@research.att.com>
To: tech-security@netbsd.org (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: <20000710150101.741C835DC2@smb.research.att.com>

*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