[ On Friday, July 11, 2003 at 18:35:36 (-0700), Greywolf wrote: ]
> Subject: Re: funlink() for fun!
>
> file descriptors work on files, not on namespace, which is what
> makes funlink(2) such a PITA to even consider implementing.

The _ONLY_ thing that makes funlink() as I've described it a PITA to
implement is the fact that unix filesystems allow multiple hard links to
files.  Everything else is just a trade-off between efficiency for the
system as a whole and the cost the caller must pay.

> NONE of the other f*(2) routines affect namespace.

Actually fpathconf() does....  :-)

It also depends on what you mean this time by "namespace".  At times
you've also implied that you think namespace and metadata have some
direct relationship and in that case fchown() and futimes() do as well.

> I think openpwd() is a poor substitute for open(...,O_NOACCESS,...),
> since it only allows one to open ".".

That could very well turn out to be a VERY good and necessary
limitation.  I've not yet thought trough all the possible consequences
in enough detail to know yet for certain.....

>  It would be much preferable to name
> a path which permits access all the way down, but which can not be
> opened for reading.

Huh?  Are you leaning towards the M$ school of OS design?  I should hope
not!  :-)


> GAW> The caller must assume it's gone for good once unlink() returns
> GAW> successfully.  Just because there was another link doesn't mean even the
> GAW> caller can find it in time to prevent the ultimate destruction of the
> GAW> underlying file and its storage.
> 
> Such an implementation would be broken.  Think about it.

No, it's most certainly not.  _YOU_ think about it.  TOCTOU race
conditions would only be the least of your problems if you try to go
down that path!

> GAW> It is absolutely impossible for a privileged process to use access()
> GAW> safely, especially if the target file is on any filesystem where
> GAW> sensitive data lives.  (despite the fact access() was intended primarily
> GAW> for the use of privileged processes)
> 
> Where do you get _this_ from?

No matter what you mean from the above, I get it from just about every
single paper, book, and sane discussion on secure Unix systems
programming since at least the early 1980's, if not before.

>  It was not very well thought out if that's
> the case.

I certainly can't speak for the designers of access(), but I do know
that there was a great deal of skepticism about such TOCTOU race
conditions up until someone finally posted a simple shell script on
Usenet that demonstrated the issue with finality.  (Perhaps it was the
"full disclosure" movement's first big win!  ;-)


> ...in which case access(2) may as well just go away, which I'm sure would
> delight quite a few people.

Me too!  ;-)

> The idea of O_NOACCESS is, I believe, in opening a directory that has
> execute-only permission, for the purposes of returning a valid fd for
> use with fchdir().

well, DUH!

> Perhaps "O_CHDIR" would be more appropriate?  That could even imply a
> check that the underlying object is, in fact, a directory, let alone
> one that can be chdir(2)d to.

Whatever you call it it's first necessary to show that it would be
useful for something other than using what's often called "safe_dir()"
and then getting back to where one started from, and I think it's also
necessary to show that openpwd() isn't a sufficient stand-in.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>