Conversation
Edited 1 month ago

I always find it a bit surprising that "looking up executables in PATH" isn't implemented in one central place (there are at least 3 implementations that I use regularly: in libc, my shell, in Go, and probably more that I don't know about)

it's a weird thing because there are actually many different implementations, but I think in general the implementations act similarly enough that you can pretend there's only 1 implementation, I've never actually run into a problem caused by this

6
2
1
@b0rk I think exploits passing e.g. PATH=. instead of the expected system value (e.g. via misconfigured sudo) can be called a "problem" :)
1
0
0

@buherator are you saying that different PATH lookup implementations handle "." in PATH differently

1
0
0
@b0rk Not exactly, but a privileged binary can take it granted that `ls` always executes `/bin/ls`, but runs an attacker provided executable instead (very stupid, but real example). Now this usually happens without switching a "PATH provider", but my gut feeling is that having "one central place" for PATH processing would've prevented at least some of these issues.
0
0
0

@b0rk Purely a matter of the rather haphazard evolution of UNIX originally. But it works.

0
0
0

@b0rk There might be differences between implementations regarding adding a new executable to a PATH directory. I think, but I'm not certain, that some notice changes in PATH directory modification times, which they use to detect a new executable without the user having to `hash -r`

1
0
0

@jgrg that's a great point, i've never run into that one personally but I've heard about it from a lot of people

0
0
0

@b0rk
In our current situation, with package managers of various kinds and most implementations being open source, it's more common to share implementations.

But I think there's still room for "protocols" -- both explicitly defined and more casual, depending on how important consistency is -- as a way for different software to interact! 😀

The PATH environment variable seems like a neat example of a simple protocol that does its job without everyone needing to depend on some complex library.

1
0
0

@apparentlymart I really like thinking about it as a protocol

0
0
0

@b0rk Linux kernel doesn’t also have one?

1
0
0

@darix I don't think so? could be wrong though

0
0
0

@b0rk i know i mentioned this before but https://savannah.gnu.org/bugs/?57962 is one that i have run into in the past

1
0
0

@doy i knew there was another thing and I forgot it was make!

0
0
0