Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!doc.ic.ac.uk!uknet!ukc!rook.ukc.ac.uk!dac From: dac@ukc.ac.uk (D.A.Clear) Newsgroups: comp.os.386bsd.bugs Subject: Re: bug with ufs file creation Date: 07 Sep 93 20:37:01 Organization: Computing Lab, University of Kent at Canterbury, UK. Lines: 52 Message-ID: <328@rook.ukc.ac.uk> References: <CCyLF6.n6@kithrup.com> <322@rook.ukc.ac.uk> <CCzu78.DJD@kithrup.com> Reply-To: dac@ukc.ac.uk (David Clear) NNTP-Posting-Host: rook.ukc.ac.uk In article <CCzu78.DJD@kithrup.com> sef@kithrup.com (Sean Eric Fagan) writes: >In article <322@rook.ukc.ac.uk> dac@ukc.ac.uk (David Clear) writes: >>That's true BSD file creation semantics > >"true BSD file creation semantics" are broken. If I cannot do > > chgrp bin foo > >without being in group bin, why is foo going to be in group bin depending >on where I create it? I think we're just coming in from different perspectives. I can't think of a time when I've not wanted a file to inherit the group id of it's parent (except for setgid programs). If I'm working in a directory in group sys, then that's what I want the files to be. Ditto for group wheel, bin, staff, etc. I don't want to have to set the setgid bit on directories all the time. I believe it's wrong to use the setgid bit to enable group id inheritance just because it's there. The BSD semantics aren't as brain-damaged as you make them out to be: tikki% groups staff wheel tikki% ls -ldg . drwxr-xr-x 2 dac games 512 Sep 7 20:02 . tikki% touch foo tikki% ls -lg foo -rw-r--r-- 1 dac games 0 Sep 7 20:04 foo tikki% chmod 2755 foo chmod: foo: Operation not permitted It won't let you make a file setgid to a group you don't belong to - as expected. I really can't stomach the idea of having to go around making everything setgid. Sounds like a very System V thing to have to do... BSD/386, DEC OSF/1 and Ultrix (to name but 3 BSD-type OSs) all use 'classic' BSD semantics. SunOS 4 gives you the choice of BSD or System V at mount time. I can see you point of view and I'll not say it's invalid, but if you really want to change the current semantics then make it a mount-time option (a la SunOS 4). Give people a choice to have the semantics they prefer on a per-filesystem basis. Regards, Dave.