Re: New sysctl entry: proc.PID.realpath

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

On Mon, Sep 07, 2015 at 09:13:11PM +0100, David Laight wrote:
 > > There's another problem this thread hasn't mentioned, which is that
 > > the result of vnode_to_path for non-directories isn't necessarily
 > > unique or deterministic even if the object hasn't been moved about.
 > 
 > Perhaps the kernel should hold a reference to the directory vnode
 > for every process.
 > An open() of the directory could then be used for $ORIGIN etc.
 > You might want this vnode to be 'revokeable' by unmount.
 > An actual path could be found using the same code ad pwd.

What directory? The one the executable was in when it was started?
That doesn't help if there are multiple links to the executable in the
same directory (not entirely uncommon once you have multiple links at
all) ... or if the executable gets moved.

I guess what you could do is: save a reference to the executable, a
reference to its containing directory when it's started, plus the
basename (final path component) from starting it. Then at lookup time,
check the directory for the basename and if that produces the same
file as the executable, return it. Otherwise, fail. This will succeed
in all the common cases at the cost of pinning down a few extra
vnodes and wasting up to NAME_MAX extra kernel memory per running
process.

It seems like a lot of work though, especially for what's ultimately a
fundamentally flawed operation. Unix has never provided a way to
translate files back to pathnames because it's inherently problematic.

For $ORIGIN, we need to either make up our minds to eat the overhead
of an extra getcwd on every non-absolute-path exec, or decide that it
will never be supported and encourage the world to move on to a less
broken interface for the purpose.

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