From owner-freebsd-security Sun Mar 9 11:55:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA07554 for security-outgoing; Sun, 9 Mar 1997 11:55:01 -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 LAA07545 for ; Sun, 9 Mar 1997 11:54:51 -0800 (PST) Received: (from uucp@localhost) by cwsys.cwent.com (8.8.5/8.6.10) id LAA00737; Sun, 9 Mar 1997 11:54:43 -0800 (PST) Message-Id: <199703091954.LAA00737@cwsys.cwent.com> Received: from localhost.cwent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwent.com, id smtpd000734; Sun Mar 9 19:54:41 1997 Reply-to: cschuber@uumail.gov.bc.ca X-Mailer: MH To: freebsd-security@freebsd.org cc: Garrett Wollman , "Daniel O'Callaghan" Subject: Re: 4.4BSD NFS File Handles (fwd) In-reply-to: Your message of "Sun, 09 Mar 1997 09:08:50 PST." <199703091708.JAA00702@cwsys.cwent.com> Date: Sun, 09 Mar 1997 11:54:41 -0800 From: Cy Schubert Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have tested my suggestion below on both of my 2.1.6 systems using the following test program; #include #include #include main() { struct stat sb; if (stat("/usr",&sb)) { perror("stat error"); exit(1); } printf("%ud\n",sb.st_gen); } The modified patch returns zero in sb.st_gen for non-root users, yet does not set the flag indicating the use of superuser powers. (I agree with Garret that filling a field via a commonly used system call does not quailfy to set the superuser-power-used flag). The patch is based on 2.1.6 as distributed on CDROM. --- sys/kern/vfs_vnops.c.orig Thu Oct 26 02:17:22 1995 +++ sys/kern/vfs_vnops.c Sun Mar 9 09:28:11 1997 @@ -395,7 +395,10 @@ sb->st_ctimespec = vap->va_ctime; sb->st_blksize = vap->va_blocksize; sb->st_flags = vap->va_flags; - sb->st_gen = vap->va_gen; + if (p->p_cred->pc_ucred->cr_uid == 0) + sb->st_gen = vap->va_gen; + else + sb->st_gen = 0; sb->st_blocks = vap->va_bytes / S_BLKSIZE; return (0); } Since I maintain a diverse range of platforms at work, five different vendors at last count, and since I build infrastructure or at least test some concepts at home, maintaining compatibility with these platforms is important to me as it reduces the number customizations I need to do for to get the same package to work on all platforms. 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." > > < 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.