On Sun Jan 04, 2026 at 09:30:18AM -0700, Theo de Raadt wrote: > 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? > >
Thank you both. Now I can see what the problem is and get the full picture.
