wtf ? If his isn't some security by obscurity right here, not sure what is. What does this achieve?

@MatejLach This has been brought up quite often - the official reason is that it will add an unreasonable amount if size (i can't remember how much) to binaries - thus breaking the already constrained (intentionally) install media.

@MatejLach also the official recommendation is to "use the full path" when executing things - like sshd does.

@MatejLach my bad. Not binary size - size in kernel overhead.

@MatejLach "Other platforms do it" is not good enough reason alone, IMHO. This has come up countless times and not once has the kernel memory overhead of tracking this information been justified (My understanding is OpenBSD doesn't keep a cached inode handy, and it could have been deleted), also many this feature is itself a hack. No software wants to inspect its own executable in any meaningful way, instead this is used to find the "directory containing the executable" at runtime.

@MatejLach This concept of supporting a Wild West of installed software locations comes from other operating systems, and is not how software has been traditionally written on Unix. As semarie@ wrote in their reply, this has typically be done at compile time in our ports tree. For example, patching in LOCALBASE (/usr/local).

@brynet So I wonder if it's never useful to be able to get resources relative to the executable? Seems pretty useful to me & the existence of this issue seems to indicate to others too.

In fact every modern language I can think of offers similar functionality.

As for it not being UNIXy, that's not a convincing argument, Unix is over half a century old at this point, it's great, but there's room for deviation.

i.e. systemd is great imo despite not following the philosophy per se.

Sign in to participate in the conversation
Matej Lach's mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!