by mail.netbsd.org with SMTP; 10 Jul 2000 18:52:12 -0000
	by columbia1-mail-router1.netops.gte.com (8.9.3/8.9.3) with ESMTP id OAA17750;
	Mon, 10 Jul 2000 14:52:11 -0400 (EDT)
From: James Chacon <jchacon@genuity.net>
	by dragon.tools.gtei.net (8.9.0/8.9.0) id OAA07589;
	Mon, 10 Jul 2000 14:52:10 -0400 (EDT)
Message-Id: <200007101852.OAA07589@dragon.tools.gtei.net>
Subject: Re: group for access to the password database
To: mrg@eterna.com.au (matthew green)
Date: Mon, 10 Jul 2000 14:52:10 -0400 (EDT)
Cc: smb@research.att.com (Steven M. Bellovin),
        tech-security@netbsd.org (NetBSD Security Technical Discussion List)
In-Reply-To: <29928.963250371@eterna.com.au> 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).

James