I suggest that "man 5 proc" should specify for /proc/[pid]/exe what happens if target executable is renamed right when open() happens. For a normal symlink, my newcomer understanding is (and I hope this isn't wrong) that first the path name is read out, then stuff can happen in between, then it is actually accessed as a separate second step. This means if the target is being renamed in just the wrong moment, a different target than intended could be opened.

From what someone anecdotally told me who seemed to understand the internal mechanics, this is NOT how open() on /proc/[pid]/exe works, in that e.g. opening /proc/self/exe can never open the wrong file if the program's binary in the moment of doing that is currently being renamed. As in, the /proc/... path doesn't appear to be actually first resolved to the final disk path as a string, during which a parallel rename could happen, and only then accessed as a 2nd step which could then go to the wrong file. That doesn't seem to be a concern.

If the man page stated that this isn't a concern for open(), that would be nice. In the same vain, it might be a good idea to point out that one shouldn't do readlink(), then open() on that path on /proc/self/exe to open a program's own binary, since that effectively reintroduces above race condition but instead open() /proc/self/exe directly. I've actually seen that done in a lot of production code, so this mistake seems to be common. (Again assuming I'm not wrong on any of this, and that this race condition exists.)

Text suggestion for the man page:

"Note on race conditions: a program opening its own binary via /proc/self/exe shouldn't use readlink() on /proc/self/exe and then open the resulting path string, since in between those two actions, the binary may have been renamed which would result in a race condition and possibly an access of the wrong file. When open() is instead used on /proc/self/exe directly, no such indirect resolution to an actual file path is done as would be for a regular symlink, but instead the target binary is safely obtained directly via its inode. (??? IS THAT CORRECT?? or just insert whatever is correct.)"

I'm sure someone smarter than me can fix this or rewrite this, but just to offer a starting point.

If you want me to forward this concern to some other place to make sure it gets into the actual linux man page source for everyone and not just openSUSE, let me know where!