Claudio Jeker <[email protected]> wrote:

> On Sun, Jan 04, 2026 at 01:04:01PM +0100, Rafael Sadowski wrote:
> > Since we do not provide KERN_PROC_PATHNAME I picked up robets@'s "hack"
> > form www/chromium/patches/patch-base_base_paths_posix_cc.
> > 
> > It certainly won't work in all cases, but it's enough for me in this 
> > context.
> > This implementation only makes sense if we don't call it too often.
> > 
> > Is KERN_PROC_PATHNAME something we generally don't want? Or was it
> > simply not implied?
> 
> We don't know the path to a vnode, now we could store the path in the
> kernel but a directory in that path could be moved and replaced. Or a
> symlink changed or the text file could be removed, ... So there is a lot
> of things that can go wrong. In all of these cases KERN_PROC_PATHNAME
> needs to return an error.
> 
> On top of all of this do those application using this sysctl even consider
> a failure of this call?

Rafael, please take a bit of time to understand what claudio wrote here.

How can such a mechanism work correctly?

The Unix model is "open" operations operate on a pathnames atomically
to create a file descriptor and you could not go back.

I've joking proposed a more reliable solution before, which would
run fts_open from "/" to find the dev_t and ino_t in the filesystem.
This would take a long time, so the function doing this would do
a syslog saying "Doing the impossible, this may take a while".

Another happy solution would be that once you open a file on a filesystem,
and remember the path and then we don't allow any files on that filesystem
to be moved or removed, unless all the fd's on the filesystem are removed.

What you want is impossible.  It is important that people understand why
it is impossible.  On systems which try to make it possible, they provide
an unreliable path, which userland applications then rely upon as if it
is truth (to the same level as an environment variable), and they typically
have extremely poor levels of failure handling.

To explain, imagine if we had such a low-quality variable available.
Shall I write a diff for sshd and ssh to use it and rely upon the fd->path
conversion?  Would that make you happy?


Reply via email to