Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Path Isn't Real on Linux

blog.danielh.cc

Post reply on HN
Print view View original

11–20 of 120 posts

Re: Path Isn't Real on Linux

#11

Post by mynegation »

inlets wrote: post #3

Why would the author think that the PATH environment variable is being used by the kernel? What an odd assumption.

You and I and bunch of other people know it and take it to be self-evident, but someone discovered it (maybe recently, maybe they have known it for a while) and did the nice write up for people who had not have known that yet. https://xkcd.com/1053/

Re: Path Isn't Real on Linux

#12

Post by thayne »

blcknight wrote: post #5

Path globbing, pipes, redirection, job control (fg/bg), and all shell variables -- not just $PATH -- are all handled by the shell. The kernel has no idea what the current process' environment $PATH is, and doesn't even parse any process environment variables at all.

PATH isn't just handled by the shell though. Many (but not all!) of the exec* family of functions in libc respect PATH.

Re: Path Isn't Real on Linux

#13

Post by LegionMammal978 »

inlets wrote: post #3

Why would the author think that the PATH environment variable is being used by the kernel? What an odd assumption.

One thing I was surprised to learn a couple years ago is that users and groups aren't really tracked much by the Linux kernel: they're just numeric IDs that track process and file ownership. So if you setuid() to a user ID that doesn't exist in /etc/passwd or anywhere else, the kernel won't stop you.

Re: Path Isn't Real on Linux

#14

Post by SuperNinKenDo »

I was trying to understand what the lede was here, and it turns out the author assumed that PATH was something understood by the kernel, which is rather an odd assumption, but perhaps one that others make.

I did get one thing out of this though. I had honestly wondered for the longest time why we need to call env to get the same functionality as PATH in a shebang.

Ironically, thanks to either an article I read here (or on the crustacean site) recently, I already knew that the shebang is something which is parsed by the kernel, but had not put two and two together at all.

Much like the author. So goes to show the benefits of exploring and thinking about seemingly "obvious" concepts.

Re: Path Isn't Real on Linux

#15

Post by latchkey »

LegionMammal978 wrote: post #13
inlets wrote: post #3

Why would the author think that the PATH environment variable is being used by the kernel? What an odd assumption.

One thing I was surprised to learn a couple years ago is that users and groups aren't really tracked much by the Linux kernel: they're just numeric IDs that track process and file ownership. So if you setuid() to a user ID that doesn't exist in /etc/passwd or anywhere else, the kernel won't stop you.

If I have a file on machineA with uid10001 and I copy the file to machineB, I might want it to retain that uid, but it shouldn't matter to machineB that it doesn't map to a real user.

Re: Path Isn't Real on Linux

#19

Post by opello »

mynegation wrote: post #11
inlets wrote: post #3

Why would the author think that the PATH environment variable is being used by the kernel? What an odd assumption.

You and I and bunch of other people know it and take it to be self-evident, but someone discovered it (maybe recently, maybe they have known it for a while) and did the nice write up for people who had not have known that yet. https://xkcd.com/1053/

The lucky 10,000 is a positive take on the situation. But the article using "real," which I think would connote to "legitimate" to most, seems a little more polarizing that sharing a discovery.

Re: Path Isn't Real on Linux

#20

Post by opello »

thayne wrote: post #12
blcknight wrote: post #5

Path globbing, pipes, redirection, job control (fg/bg), and all shell variables -- not just $PATH -- are all handled by the shell. The kernel has no idea what the current process' environment $PATH is, and doesn't even parse any process environment variables at all.

PATH isn't just handled by the shell though. Many (but not all!) of the exec* family of functions in libc respect PATH.

It seems too far to go to say that because a system library holds some implementation details that the responsibility doesn't lie with the program using them. There's all sorts of complex interdependent details that make those kind of boundary distinctions difficult in many operating systems.
Post reply on HN