Return to BSD News archive
Xref: sserve comp.os.386bsd.development:2266 comp.os.linux.development:10410 Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!agate!howland.reston.ans.net!math.ohio-state.edu!jussieu.fr!univ-lyon1.fr!ensta!bsdtest.ensta.fr!bouyer From: bouyer@bsdtest.ensta.fr (Manuel Bouyer) Newsgroups: comp.os.386bsd.development,comp.os.linux.development Subject: Re: Subtle NFS problem in BSD and Linux Date: 15 Jun 1994 18:30:32 GMT Organization: Ecole Nationale Superieure de Techniques Avancees, Paris Lines: 39 Distribution: world Message-ID: <2tnhc8$dsi@ici-paris.ensta.fr> References: <2tnfgn$4o7@darkstar.UCSC.EDU> NNTP-Posting-Host: bsdtest.ensta.fr In article <2tnfgn$4o7@darkstar.UCSC.EDU>, haynes@cats.ucsc.edu (James H. Haynes) writes: |> |> SunOS 4.1.x has a mount option "grpid" which says, if you mount a disk |> partition with that option, to use BSD semantics for file groups regardless |> of the setgid bit on directories. That is, if a disk partition is mounted |> with the grpid option then a newly-created file anywhere in that partition |> has the group ownership taken from the group owner of the containing |> directory. Without the grpid mount option the above group ownership |> behavior occurs if the containing directory has the setgid bit turned on; |> otherwise the group of a newly created file is the current group of the |> creator. |> |> I've found experimentally with a Sun NFS server that the grpid mount |> option works as expected when the NFS client is a Sun, and not when the |> client is BSD (approximately FreeBSD 0.9 plus something) or Linux |> (approximately Slackware 1.1). |> |> Specifically, here's output from ls -lga on the server |> drwxrwx--- 2 haynes cmp101-admin 512 Jun 15 10:58 ./ |> drwsrwx-wt 8 avg cmp101-admin 512 Jun 14 20:51 ../ |> -rw-rw---- 1 haynes sources 8 Jun 15 10:22 junk.bsd |> -rw-rw---- 1 haynes sources 8 Jun 15 10:22 junk.linux |> -rw-rw---- 1 haynes cmp101-admin 8 Jun 15 10:22 junk.sparc |> |> where the various junk files were created from an NFS client on the systems |> indicated by the suffixes. I've got the same kind of problem whith NetBSD. This is a bug from SunOS. Whith NFS filesystem, for security reasons, the filesystem semantic should be fixed by the server. NetBSD handle nfs like this, and i think Linux and FreeBSD too. SunOS doesn't for the group id, but it does or other things, like the propagation of the SGID bit. I've fixed this by a patch of my NetBSD's NFS code, because i don't have SunOS sources. -- Manuel Bouyer, Ecole Nationale Superieure de Techniques Avancees, Paris email: bouyer@ensta.fr --