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 dholl...@netbsd.org