From owner-freebsd-bugs  Sun Dec 22 08:50:04 1996
Return-Path: <owner-bugs>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id IAA10553
          for bugs-outgoing; Sun, 22 Dec 1996 08:50:04 -0800 (PST)
Received: (from gnats@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id IAA10541;
          Sun, 22 Dec 1996 08:50:01 -0800 (PST)
Date: Sun, 22 Dec 1996 08:50:01 -0800 (PST)
Message-Id: <199612221650.IAA10541@freefall.freebsd.org>
To: freebsd-bugs
Cc: 
From: Bradley Dunn <bradley@dunn.org>
Subject: Re: bin/2265: su(1) does not call skeyaccess()
Reply-To: Bradley Dunn <bradley@dunn.org>
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: Bradley Dunn <bradley@dunn.org>
To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>
Cc: FreeBSD-gnats-submit@freebsd.org, Guido van Rooij <guido@gvr.win.tue.nl>
Subject: Re: bin/2265: su(1) does not call skeyaccess()
Date: Sun, 22 Dec 1996 11:41:41 -0500 ()

 On Sun, 22 Dec 1996, J Wunsch wrote:
 
 > As bradley@dunn.org wrote:
 > 
 > > >Description:
 > > 
 > > 	su(1) does not call skeyaccess() (from libskey), thus rendering the
 > > controls in /etc/skey.access useless.
 > 
 > Well, it rather seems like it was deliberately omitted, as opposed to
 > forgotten.  A user running su(1) has already been authenticated to the
 > system, and _that's_ where skey.access should hit.
 
 Someone running su(1) has already been authenticated, but as someone else.
 
 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.
 
 -BD