From owner-freebsd-bugs  Thu Dec 26 04:30:04 1996
Return-Path: <owner-bugs>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id EAA18921
          for bugs-outgoing; Thu, 26 Dec 1996 04:30:04 -0800 (PST)
Received: (from gnats@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id EAA18907;
          Thu, 26 Dec 1996 04:30:02 -0800 (PST)
Date: Thu, 26 Dec 1996 04:30:02 -0800 (PST)
Message-Id: <199612261230.EAA18907@freefall.freebsd.org>
To: freebsd-bugs
Cc: 
From: Guido van Rooij <guido@gvr.win.tue.nl>
Subject: Re: bin/2265: su(1) does not call skeyaccess()
Reply-To: Guido van Rooij <guido@gvr.win.tue.nl>
Sender: owner-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

The following reply was made to PR bin/2265; it has been noted by GNATS.

From: Guido van Rooij <guido@gvr.win.tue.nl>
To: bradley@dunn.org (Bradley Dunn)
Cc: joerg_wunsch@uriah.heep.sax.de, FreeBSD-gnats-submit@freebsd.org
Subject: Re: bin/2265: su(1) does not call skeyaccess()
Date: Mon, 23 Dec 1996 18:12:57 +0100 (MET)

 Bradley Dunn wrote:
 > Someone running su(1) has already been authenticated, but as someone else.
 > 
 
 Correct.
 
 > I think that if one puts a "deny user foo" in skey.access, the intention
 > is that foo should not be able to gain access to the system using foo's
 > UNIX password. With the current su, foo has a way of gaining access with
 > his UNIX password, even though it is desired that he not be able to.A
 
 All of your reasoning is correct. If there's enough demand, I'll add
 the su skey code to su.
 Btw: there is a manpage for skey.access:
 	skey.access(5)           - S/Key password control table
 
 
 -Guido