namei and path canonicalization

[David Holland <dholland-tech%netbsd.org@localhost>]

Currently namei is supposed to canonicalize paths as it processes
them. It turns out that this is broken and has been for some time
(likely since before -6) -- also the feature is a significant source
of complexity and does not really serve any useful purpose. Therefore,
I'd like to remove it.

There are two consumers of this behavior at the moment: (1)
compat_svr4 uses it to provide realpath() as a system call, and (2)
the code for supplying $ORIGIN to programs sometimes uses it. The
first we probably don't care about, and we can if necessary replace it
with a LOCKPARENT lookup and getcwd. The second is bogus.

First of all, there is no need to provide a canonicalized path in
$ORIGIN, just a path. The victim^W application can call realpath()
itself if it cares for some reason. It is sufficient to provide either
the path passed to exec, or if that's not absolute, that spliced to
getcwd output.

Canonicalizing the path during lookup removes some cases where the
lookup potentially races with namespace rearrangements; but not all of
them. It's still fundamentally unsafe for a setugid program, or any
other program that would need to care about such rearrangements
happening while it's starting, to use the path supplied in $ORIGIN.

(We should explicitly not provide $ORIGIN in setugid programs.)

Second, if we want a robust way for a program to find its installation
prefix instead of compiling it in, that should be done by remembering
the directory vnode the program was exec'd from and providing a way to
open it as a file handle. Then the program can look for its
libraries/plugins/whatever with openat().

(A better still way to do this is to just compile in paths and have a
way to update the compiled-in paths for an existing binary, but I
digress.)

Third, we should not invent a lot of complicated machinery to satisfy
the odd notions that some existing software apparently has about
trying to extract paths to its own executable. Things like
/proc/self/exe should contain either accurate information or no
information (like they do now), not ad hoc approximations to correct
information to work around the lack of a robust way to discover
$PREFIX, or to work around programs that do stupid things instead of
using that robust mechanism.


If we want to provide a slightly more robust path than just copying
the exec argument, we can do the following:
   - use namei with LOCKPARENT so as to get the containing directory
   - call getcwd on that
   - splice the last component of the exec argument onto the getcwd
     result

However, this increases the number of getcwd calls (though most of
them will be satisfied from the namecache) and serves little purpose
relative to the simpler method.

-- 
David A. Holland
dholland%netbsd.org@localhost