by mail.netbsd.org with SMTP; 13 Jul 2000 18:07:56 -0000
	by mail-blue.research.att.com (Postfix) with ESMTP
	id F2B074CE27; Thu, 13 Jul 2000 14:07:55 -0400 (EDT)
	by postal.research.att.com (8.8.7/8.8.7) with ESMTP id OAA01436;
	Thu, 13 Jul 2000 14:07:54 -0400 (EDT)
	by smb.research.att.com (Postfix) with ESMTP
	id 244C235DC2; Thu, 13 Jul 2000 14:07:41 -0400 (EDT)
From: "Steven M. Bellovin" <smb@research.att.com>
To: lukem@cs.rmit.edu.au
Cc: matthew green <mrg@eterna.com.au>,
	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: Thu, 13 Jul 2000 14:07:38 -0400
Message-Id: <20000713180741.244C235DC2@smb.research.att.com>

In message <200007130703.RAA24792@wombat.cs.rmit.edu.au>, Luke Mewburn writes:
>"Steven M. Bellovin" writes:
>>> ... 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.
>
>Not necessarily; if the communication was done inside getpw*() it
>would be transparent to the caller, just as the decision to use
>/etc/passwd or /etc/master.passwd in the current code is transparent
>to the caller.
>
I had suggested a mechanism that just gave a Y/N answer, rather than 
one that passed back the hash password.


		--Steve Bellovin