Just a thought;

but why not a reserve(path,mode,uid,gid) and ropen() (reserved open) call
if there is a concern about security?  It's that half-open thing that
was discussed a while ago, but actually separated out into two calls;

reserve() would return a filehandle of sorts which could then be passed to
ropen() to return a descriptor?  One could also have an rstat() call to
stat the filehandle and find out what you've reserved.  Since the reserve
would lock the node, the rstat() would be guaranteed to return valid
information, and ropen() would be guaranteed to return a valid fd into
the data, even if an unlink() has transpired.

Or is this too akin to the earlier discussion to be of value?

It seems to me probably a bit extreme, though, to go through these hoops
to accomplish something that is probably best solved in another way,
although a reserve() call would be GREAT for things like temp files...

On Thu, 23 Nov 2000, Warner Losh wrote:

# Date: Thu, 23 Nov 2000 23:07:26 -0700
# From: Warner Losh <imp@village.org>
# To: Noriyuki Soda <soda@sra.co.jp>
# Cc: tech-kern@netbsd.org
# Subject: Re: Addition to force open to open only regular files 
# 
# In message <200011231325.WAA05898@srapc342.sra.co.jp> Noriyuki Soda writes:
# : There is no exploit that open_as() can fix but saved-ID feature
# : cannot fix. Thus, open_as() is not needed.
# 
# Without seeing a good API on open_as, I'm inclined to agree.  Even
# with a good API, I'd be inclidned to agree.  There's no way to get the
# saved id's that people would want to use with the parameter to the
# open_as call.  At least not in a library.  I've not seen how this can
# be done in this thead unless theres a getsuid() and a getsgid() system
# call added as well.  And if there is, one can always do the seteuid()
# trick that soda-san has been talking about, unless the process has
# used setreuid() to do its ID swapping, in which case you can't do the
# id swapping.
# 
# People seem to want an access(2) like system call that is really an
# open_with_saved_id() rather than an open_as() since you'd want to
# restrict the open_as semantics to only be a few select uids.  If you
# open the file with the right creditials, doing the double open dance
# is just a waste and unnessary.  If someone is racing you, it doesn't
# matter since if you win the race, you open a file you have access to,
# if you lose, you can't.
# 
# On a political note, I suspect that there will be a lot of pressure
# for the other BSDs to pick up things like this, and I strongly suspect
# that it will be an extreme firefight to get it into FreeBSD.  It seems
# too specialized to be worth the fight.
# 
# It seems that the introduction of setr*id() has caused more problems
# than the minor compatibility that it gave with other systems. :-)
# 
# Warner
# 


				--*greywolf;
--
*BSD: Professional power!