Stuart Henderson <[email protected]> wrote: > On 2021/02/02 21:18, Greg Steuck wrote: > > Added a patch from upstream to work around a case of > > "all-world-is-Linux"ism. > > That's not really true; pretty much every OS other than OpenBSD has a > way to determine the path that the current executable was started from.
And in some cases, return a lie, but the application cannot tell that it has been lied to. Others spuriously return a "don't know" type error. And then what do the applications do? Well that depends on the application, some carry on fine because it turns out the path information was less crucial than expected, others behave incorrectly, others fail. > There are various different ways of course (there's a little project > https://github.com/gpakosz/whereami which copes with the variants used > on qnx, sunos, osx, freebsd, netbsd, linux, android and windows). By various different ways, you mean the behaviour of the enquiry > Suggestions of adding this to OpenBSD have been rejected before, > I think mostly because it won't track unlink or name changes via rename. No, that is not why. It has been rejected because it is IMPOSSIBLE to reverse an inode to a pathname with an O(1) algorithm. Furthermore a potential path we might return is a mix of current-dir-vnode/inode (with path unknown) and relative-path (which is converted to a new vnode/inode). Thus, best effort would require storing a relative path (and updating it) per-vnode. Ignoring the issue of hard links, we can't actively scan the path heirarchy (via multiple layers of mounted filesystems) to determine where the inode is, at request time. > For the purposes of every program I've seen that uses this information > (including sshd, which uses argv[0] to obtain it by requiring the > full path when it's invoked), "path that the process was started > under" is exactly what they want and tracking through renames would > not give the information they need. sshd has an important reason: privsep fork+exec. Most other programs have far less important reason to do this -- it is likely some of them come from a authors more familiar with non-Unix environments where the file-heirarchy isn't constructed from layered mountpoints with a one-way filename->node mapping. We could easily have an API which always returns with an incorrect path, or indicator that we don't know. After all, on all of the systems listed about there WILL BE a situation where the path cannot be determined, just give the applications that error.
