>>>> Maybe I'm missing something here, but it seems to me that there
>>>> are times that you don't want to follow symlinks.

>> Yeah, there are. :-)

> Name one.  "Cleaning up /tmp and /var/tmp" is not an example because
> /tmp, /var, or /var/tmp might themselves be symlinks

How does the antecedent follow from the consequent?  If you'd look at
my example, you'd've seen that it explicitly defers disabling symlink
interpretation until after chdir()ing to /tmp.

> We have established that, using fchdir(), you can avoid following
> symlinks within /tmp,

Not to my satisfaction.  You can have over five thousand levels of
directory to walk through and - at least on the NetBSD systems I have
access to - only between three and four hundred (not thousand) file
descriptors available.  So even if you were willing to go to the
trouble of doing the filesystem walk with fchdir(), the code complexity
would quickly get - in my opinion - unmanageable.

> so there is no reason to muck with the kernel to get around this
> security hole.

How many security holes have you seen that involve switching symlinks?
Certainly lots of the ones _I've_ seen have.  It's true that most of
those programs would fall over pretty hard in many environments if they
were to run with symlinks disabled...but if the facility were
available, I believe it would make it comparatively easy to code such
things in ways significantly more secure than what's done now.

Alternatively, if there were an O_NOIO and then file-descriptor
versions of the various syscalls that currently perform path walks,
similar secure recoding would be possible, in a different paradigm,
especially if you add an O_NEVERFOLLOWLINKSANYWHERE.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B