From owner-freebsd-security  Sun Mar  9 09:09:41 1997
Return-Path: <owner-security>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id JAA00920
          for security-outgoing; Sun, 9 Mar 1997 09:09:41 -0800 (PST)
Received: from cwsys.cwent.com (0@cschuber.net.gov.bc.ca [142.31.240.113])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA00915
          for <freebsd-security@freebsd.org>; Sun, 9 Mar 1997 09:09:37 -0800 (PST)
Received: (from uucp@localhost) by cwsys.cwent.com (8.8.5/8.6.10) id JAA00702; Sun, 9 Mar 1997 09:08:59 -0800 (PST)
Message-Id: <199703091708.JAA00702@cwsys.cwent.com>
Received: from localhost.cwent.com(127.0.0.1), claiming to be "cwsys"
 via SMTP by localhost.cwent.com, id smtpd000699; Sun Mar  9 17:08:51 1997
Reply-to: cys@mailhost.wlc.com
X-Mailer: MH
To: Garrett Wollman <wollman@lcs.mit.edu>
cc: "Daniel O'Callaghan" <danny@panda.hilink.com.au>,
        freebsd-security@freebsd.org
Subject: Re: 4.4BSD NFS File Handles (fwd) 
In-reply-to: Your message of "Fri, 07 Mar 1997 09:30:13 EST."
             <9703071430.AA26267@halloran-eldar.lcs.mit.edu> 
Date: Sun, 09 Mar 1997 09:08:50 -0800
From: Cy Schubert <cy@cwsys.cwent.com>
Sender: owner-security@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> <<On Fri, 7 Mar 1997 16:15:41 +1100 (EST), "Daniel O'Callaghan" <danny@panda.
hilink.com.au> said:
> 
> >         if (suser(p->p_ucred, &p->p_acflag)) {
> >		sb->st_gen = 0;
> >         } else {
> >		sb->st_gen = vap->va_gen;
> >         }
> 
> This test is bogus.  The problem is that is causes p_acflag to get the
> ``used superuser privileges'' bit set every time a root process calls
> stat().  Since most processes call stat() at least once in their
> lifetime, this would make p_acflag completely useless.

Agreed.  Replacing the "if (suser(p->p_ucred, &p->p_acflag)) {" in the
patch with "if (p->p_cred->pc_ucred->cr_uid == 0) {" should address this
concern.

> 
> I'm certainly willing to live with not making this information
> available through the stat(2) interface at all.  Any process with
> appropriate privilege can simply read the information off the disk
> anyway, so I don't see any benefit in having it here.  (A process with
> appropriate privilege can also call getfh(2) and parse the returned
> handle.)

I disagree.  This field is returned by other UNICES, notably DEC UNIX among
others.  Removing it would cause some portability concerns in some cases,
e.g. some code may not compile right-out-of-the-box.


Regards,                       Phone:  (250)387-8437
Cy Schubert                      Fax:  (250)387-5766
UNIX Support                   OV/VM:  BCSC02(CSCHUBER)
ITSD                          BITNET:  CSCHUBER@BCSC02.BITNET
Government of BC            Internet:  cschuber@uumail.gov.bc.ca
                                       cschuber@bcsc02.gov.bc.ca

                "Quit spooling around, JES do it."