Re: New sysctl entry: proc.PID.realpath

[David Laight <david%l8s.co.uk@localhost>]

On Mon, Sep 07, 2015 at 07:01:45PM +0000, David Holland wrote:
> On Mon, Sep 07, 2015 at 11:13:35AM +0200, Joerg Sonnenberger wrote:
>  > > Two nits:
>  > > 
>  > >  1) vnode_to_path(9) is undocumented
>  > >  2) it only works if you are lucky (IIUC) - which you mostly are
>  > > 
>  > > The former is easy to fix, the latter IMHO is a killer before we expose
>  > > this interface prominently and make debuggers depend on it. We then should
>  > > also make $ORIGIN work in ld.elf_so ;-}
>  > 
>  > My suggestion was to just provide the filesystem id and inode number as
>  > fallback. I still believe we should just turn on the code that remembers
>  > the realpath on exec in first place, if you want to debug
>  > something_with_a_very_very_very_very_..._very_long_name, you can always
>  > override the (missing) default.
> 
> As best I recall (having tried to page the context in the past few
> days) the only reason that code is disabled is so that it fails in a
> way that's readily explainable (non-absolute paths) vs. arbitrarily
> and capriciously.
> 
> 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.

	David

-- 
David Laight: david%l8s.co.uk@localhost