Re: namei and path canonicalization

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

On Tue, Nov 07, 2017 at 10:20:27PM +0000, David Holland wrote:
 > 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.)

Actually, let me strengthen that: there are two cases -- either
someone is rearranging the namespace while all this is happening, or
not. In the latter case, providing the path string handed to exec is
sufficient. In the former case, there's no amount of machination that
will produce a string that's safe/accurate to use for these purposes,
and there's no point trying.

Also it occurs to me that there's no reason for the kernel to do the
getcwd call; it should just provide the argument given to exec in all
cases, and ld.so can do the getcwd call itself if necessary (if the
string it finds doesn't begin with '/') when/if something uses
$ORIGIN.

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