Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: getcwd() and friends.
Message-ID: <1419@auspex.auspex.com>
Date: 10 Apr 89 20:02:59 GMT
References: <3675@ficc.uu.net> <14689@rpp386.Dallas.TX.US> <811@mtxinu.UUCP> <4438@psuvax1.cs.psu.edu> <2001@unisoft.UUCP> <4445@psuvax1.cs.psu.edu> <1410@auspex.auspex.com> <FLEE.89Apr9034427@shire.cs.psu.edu>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 21

>>>For one thing, we could introduce O_CHMOD to open for mode changes.
>>No, not worth it.  "fchmod" can - and does - already check whether you
>>have permission to do a "chmod".
>
>Er, the point is to fchmod a file that you don't have permission to
>open.  You need to open a file for no access (O_OPEN?).

Er, the complaint wasn't that you don't need a new flavor of open, the
complaint was that you don't need a new flavor of open *that's specific
to "chmod", and that does permission checking*.  From the article to
which I was replying:

	For one thing, we could introduce O_CHMOD to open for mode
	changes.  The open would succeed iff the opener had
	permission to do a chmod.

O_OPEN is *all* you need; you don't need O_CHMOD and O_CHOWN and O_this
and O_that, since the call that uses the file descriptor can check the
permissions itself (and does, in the case of "fchmod", for example). 
O_CHMOD doesn't buy you anything worthwhile that O_OPEN doesn't;
assuming it's worth adding O_OPEN, it's not worth adding O_CHOWN.