Thank you so very much!! that was very insightful about looking at the source for fstat. I Have code the checks for the correct ino_t and dev_t now thanks to you.
Here's what I'm doing for those interested in seeing: https://github.com/time-killer-games/xproc/commit/03a643a7d33e679994f4896acfca7a9fa7d5467f Cheers, Samuel ________________________________________ From: Stuart Henderson [s...@spacehopper.org] Sent: Tuesday, July 26, 2022 4:11 AM To: Samuel Venable Cc: tech@openbsd.org Subject: Re: On 2022/07/25 20:08, Samuel Venable wrote: > I have a suggestion on how to get the current executable path in OpenBSD that > might be reliable enough and not too costly that it might be accepted for a > future OpenBSD version. > > Even if it won't be accepted, I need a little help completing the solution I > have in mind. > > The current solution relies on $PWD, $PATH, and argv[0] to guess the > most-likely executable path if $PWD, $PATH, or arv[0] were not modified from > their original values. That's the only way to do it on OpenBSD other than hard-coding the "expected" location (which we do in some ports). btw that is what's implemented by the permissibly-licensed "whereami" library that isolates the OS-dependent code from the application calling it and supports a wide range of OS. https://github.com/gpakosz/whereami/commit/c47b123fe9d7d7a148d97151c51a9fc4c236ea83 >From past discussion (which I don't feel like looking up, but you'll find some in the mailing list archives, maybe on ports@) don't expect this to change. > "I've come up with a means to get a proper error code if the executable path > returns a path to the wrong file. Basically if meams getting the vnode from > the current process id, get the stat struct from the vnode, the compare a few > stat structure members with the stat structure returned by opening the path > the function guessed points to the current executable. It involves working > with a lot of kernel functions which do have documentation but for one reason > or another I can't get any of it to compile because linking errors, and the > docs don't say anything about what libraries I should be linking to. It will > take a while, but this is a lot better." I think you're overthinking this. The equivalent functionality on other OS is not reliable either so a best-effort approach should be good enough for any use to which a program might put this information. (In most cases that I've seen it's done to find a path to other resources used by the program without relying on a compiled-in value). If you really want this type of checking, see how fstat(1) works and check the inode num. But until a bug is fixed you'll crash the kernel from time to time.
