6 ms·

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

by inlets 1y ago

deleted 1y ago
[deleted]
quotemstr 1y ago
Well, execve(2) and execvp(3) are both "system" functions. C (which is already black magic for some people) invokes both by calling into functions exported from libc. If you're not super dorky^Wfamiliar with low-level systems stuff, you might guess that the two functions are implemented in the same place and in the same way. That the latter is just a libc wrapper around the former that does a PATH search is arcane detail you don't have to care about 99% of the time. It's hard to appreciate how the world looks before you learn a fact. You can't unsee things.
- Aloisius 1y ago
  But the man page section tells you which one is is a a kernel syscall (2) and which is a C library function (3)...
  - Joker_vD 1y ago
    Which is the universally known convention everyone is born with inherent knowledge of. Also, people read man-pages.
    - Aloisius 1y ago
      What person diving into their shell's source code on Linux doesn't read manpages? Or even man's manpage at least once?
      - Joker_vD 1y ago
        Daniel Huang, the one that wrote TFA? People are different, I don't know what else to tell you. But generally, people don't read man pages or docs.
deleted 1y ago
[deleted]
mynegation 1y ago
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/ https://xkcd.com/1053/
- opello 1y ago
  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.
  - mynegation 1y ago
    Click bait title for sure
LegionMammal978 1y ago
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.
- latchkey 1y ago
  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.
  - MrDarcy 1y ago
    You’ll see this observation all the time building containers.
    - danielrico 1y ago
      Don't if you only run them with root user.
    - kurisufag 1y ago
      or with ipa-esque authentication schemes and shared mounts
    - dimatura 1y ago
      And NFS!
  - rafram 1y ago
    Hopefully that user actually doesn’t exist on the second machine!
MisterTea 1y ago
Ignorance leading to assumptions. Their eureka moment: "The shell, not the Linux kernel, is responsible for searching for executables in PATH!" makes it obvious they haven't read up on operating systems. Shame because you should know how the machine works to understand what is happening in your computer. I always recommend reading Operating Systems: Three Easy Pieces. https://pages.cs.wisc.edu/~remzi/OSTEP/ https://pages.cs.wisc.edu/~remzi/OSTEP/
- quotemstr 1y ago
  The thing is, though, that PATH being a userspace concept is a contingent detail, an accident of history, not something inherent to the concept of an operating system. You can imagine a kernel that does path searches. Why not? There's a difference between something being a certain way because it has to be that way in order to implement the semantics of the system (e.g. interrupt handlers being a privilege transition) and something being a certain way as a result of an arbitrary implementation choice. OSes differ on these implementation choices all the time. For example, * in Linux, the kernel is responsible for accepting a list of execve(2) argument-words and passing them to the exec-ed process with word boundaries intact. On Windows, the kernel passes a single string instead and programs chop that string up into argument words in userspace, in libc * in Linux, the kernel provides a 32-bit system call API for 32-bit programs running on 64-bit kernels; on Windows, the kernel provides only a 64-bit system call API and it's a userspace program that does long-mode switching and system call argument translation * on Windows, window handles (HWNDs, via user32.dll) in IPC message passing (ALPC, in ntoskrnl) are implemented in the kernel, whereas the corresponding concepts on most Linux systems are pure user-space constructs And that's not even getting into weirder OSes! Someone familiar with operating systems in general can nevertheless be surprised at how a particular OS chooses to implement this or that feature.
  - amiga386 1y ago
    * in Linux, the kernel is responsible for accepting a list of execve(2) argument-words Yes it does, but the more surprising thing is (coming from AmigaOS with its dos.library function ReadArgs()) that the shell does this. The shell is also responsible for argument expansion - madness! On AmigaOS, when you type "delete foo#? force", the shell passes the entire command line to the delete command. The delete command calls ReadArgs() with a template (FILE/M/A, ALL/S, QUlET/S, FORCE/S), and the standard OS function parses it into lists of files, flags, keyword arguments, etc. The "file" passed is "foo#?", and the command uses MatchFirst()/MatchNext() to do file pattern matching. Every command (that uses ReadArgs() and didn't plump for "standard C" parsing) has the same behaviour: running the command with "?" gives you the template, which tells you how to use it. Args are parsed consistently across all programs. Then you get "standard C", which because K&R and main(), ignores this standard Amiga parsing function and just does naive splits. Across multiple Amiga C compilers, quoting rules are inconsistent. Amiga C compilers have to produce an executable, and it knows it'll be called with a full command line, so the executable itself has to break that into words before it can call main(), and it's up to each compiler writer how they're going to do that. Urgh. In unix-land, it's up to the shell to parse the command line, and pass only the words... hence why the shell naturally does all the filename globbing, and why you have gotchas like when these two commands are sometimes the same and sometimes they're not: find . -name foo* find . -name 'foo*' Then we have Windows, which is like Amiga C programs - it's being passed a full command string and will have its C runtime parse it for main() to consume. There's a vague expectation that it'll do quoting "like COMMAND", which itself has very odd quoting rules. At least, most people are all using the same C compiler on Windows, so it's mostly only MSVCRT's implementation so it's mostly consistent.
klysm 1y ago
I don't think it's an odd assumption at all! The lines between shell, exec calls, globbing, etc, are very blurry if you don't already know how it all fits together.
rafram 1y ago
Unnecessarily rude. There was also a time when you didn’t know this. I can guarantee it!
- xeyownt 1y ago
  The question is why author wrote such a clickbait title and made such an odd conclusion? Legitimate question IMO, nothing rude there. It's not about knowledge, but about assumptions. The title and conclusion hint that there are some obvious assumptions, but these are not detailed. Maybe author assumed that because of the ubiquitous use of PATH across shells, it had to be managed centrally.
Joker_vD 1y ago
Why not? Every executable is started with execve(2) syscall which takes an array of the environment variables that the kernel use to reset the process's environment variables it inherited from its parent, so obviously the kernel has full knowledge of the environment variables of all of the processes in the system. Now, there is a reason why kernel actually does not have such knowledge, but it's not at all unreasonable to assume that the kernel has it.
- matheusmoreira 1y ago
  The thing that really blows minds is the fact Linux does not do name resolution at all. Getting rid of glibc breaks a lot of stuff because everyone depends on glibc to do it. https://wiki.archlinux.org/title/Domain_name_resolution https://wiki.archlinux.org/title/Domain_name_resolution https://en.wikipedia.org/wiki/Name_Service_Switch https://en.wikipedia.org/wiki/Name_Service_Switch https://man.archlinux.org/man/getaddrinfo.3 https://man.archlinux.org/man/getaddrinfo.3
dzaima 1y ago
That's not a truth that'd come from first principles, never mind a trivial truth; it's extremely trivial to imagine a kernel that does parse PATH where it wouldn't be true. As such, it's a thing one has to explicitly look up to know, which the author did.

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

by inlets 1y ago

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

deleted 1y ago

[deleted]

quotemstr 1y ago

Well, execve(2) and execvp(3) are both "system" functions. C (which is already black magic for some people) invokes both by calling into functions exported from libc. If you're not super dorky^Wfamiliar with low-level systems stuff, you might guess that the two functions are implemented in the same place and in the same way. That the latter is just a libc wrapper around the former that does a PATH search is arcane detail you don't have to care about 99% of the time. It's hard to appreciate how the world looks before you learn a fact. You can't unsee things.

Aloisius 1y ago
But the man page section tells you which one is is a a kernel syscall (2) and which is a C library function (3)...
- Joker_vD 1y ago
  Which is the universally known convention everyone is born with inherent knowledge of. Also, people read man-pages.
  - Aloisius 1y ago
    What person diving into their shell's source code on Linux doesn't read manpages? Or even man's manpage at least once?
    - Joker_vD 1y ago
      Daniel Huang, the one that wrote TFA? People are different, I don't know what else to tell you. But generally, people don't read man pages or docs.

deleted 1y ago

[deleted]

mynegation 1y ago

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/ https://xkcd.com/1053/

opello 1y ago
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.
- mynegation 1y ago
  Click bait title for sure

LegionMammal978 1y ago

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.

latchkey 1y ago
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.
- MrDarcy 1y ago
  You’ll see this observation all the time building containers.
  - danielrico 1y ago
    Don't if you only run them with root user.
  - kurisufag 1y ago
    or with ipa-esque authentication schemes and shared mounts
  - dimatura 1y ago
    And NFS!
- rafram 1y ago
  Hopefully that user actually doesn’t exist on the second machine!

MisterTea 1y ago

Ignorance leading to assumptions. Their eureka moment: "The shell, not the Linux kernel, is responsible for searching for executables in PATH!" makes it obvious they haven't read up on operating systems. Shame because you should know how the machine works to understand what is happening in your computer. I always recommend reading Operating Systems: Three Easy Pieces. https://pages.cs.wisc.edu/~remzi/OSTEP/ https://pages.cs.wisc.edu/~remzi/OSTEP/

quotemstr 1y ago
The thing is, though, that PATH being a userspace concept is a contingent detail, an accident of history, not something inherent to the concept of an operating system. You can imagine a kernel that does path searches. Why not? There's a difference between something being a certain way because it has to be that way in order to implement the semantics of the system (e.g. interrupt handlers being a privilege transition) and something being a certain way as a result of an arbitrary implementation choice. OSes differ on these implementation choices all the time. For example, * in Linux, the kernel is responsible for accepting a list of execve(2) argument-words and passing them to the exec-ed process with word boundaries intact. On Windows, the kernel passes a single string instead and programs chop that string up into argument words in userspace, in libc * in Linux, the kernel provides a 32-bit system call API for 32-bit programs running on 64-bit kernels; on Windows, the kernel provides only a 64-bit system call API and it's a userspace program that does long-mode switching and system call argument translation * on Windows, window handles (HWNDs, via user32.dll) in IPC message passing (ALPC, in ntoskrnl) are implemented in the kernel, whereas the corresponding concepts on most Linux systems are pure user-space constructs And that's not even getting into weirder OSes! Someone familiar with operating systems in general can nevertheless be surprised at how a particular OS chooses to implement this or that feature.
- amiga386 1y ago
  * in Linux, the kernel is responsible for accepting a list of execve(2) argument-words Yes it does, but the more surprising thing is (coming from AmigaOS with its dos.library function ReadArgs()) that the shell does this. The shell is also responsible for argument expansion - madness! On AmigaOS, when you type "delete foo#? force", the shell passes the entire command line to the delete command. The delete command calls ReadArgs() with a template (FILE/M/A, ALL/S, QUlET/S, FORCE/S), and the standard OS function parses it into lists of files, flags, keyword arguments, etc. The "file" passed is "foo#?", and the command uses MatchFirst()/MatchNext() to do file pattern matching. Every command (that uses ReadArgs() and didn't plump for "standard C" parsing) has the same behaviour: running the command with "?" gives you the template, which tells you how to use it. Args are parsed consistently across all programs. Then you get "standard C", which because K&R and main(), ignores this standard Amiga parsing function and just does naive splits. Across multiple Amiga C compilers, quoting rules are inconsistent. Amiga C compilers have to produce an executable, and it knows it'll be called with a full command line, so the executable itself has to break that into words before it can call main(), and it's up to each compiler writer how they're going to do that. Urgh. In unix-land, it's up to the shell to parse the command line, and pass only the words... hence why the shell naturally does all the filename globbing, and why you have gotchas like when these two commands are sometimes the same and sometimes they're not: find . -name foo* find . -name 'foo*' Then we have Windows, which is like Amiga C programs - it's being passed a full command string and will have its C runtime parse it for main() to consume. There's a vague expectation that it'll do quoting "like COMMAND", which itself has very odd quoting rules. At least, most people are all using the same C compiler on Windows, so it's mostly only MSVCRT's implementation so it's mostly consistent.

klysm 1y ago

I don't think it's an odd assumption at all! The lines between shell, exec calls, globbing, etc, are very blurry if you don't already know how it all fits together.

rafram 1y ago

Unnecessarily rude. There was also a time when you didn’t know this. I can guarantee it!

xeyownt 1y ago
The question is why author wrote such a clickbait title and made such an odd conclusion? Legitimate question IMO, nothing rude there. It's not about knowledge, but about assumptions. The title and conclusion hint that there are some obvious assumptions, but these are not detailed. Maybe author assumed that because of the ubiquitous use of PATH across shells, it had to be managed centrally.

Joker_vD 1y ago

Why not? Every executable is started with execve(2) syscall which takes an array of the environment variables that the kernel use to reset the process's environment variables it inherited from its parent, so obviously the kernel has full knowledge of the environment variables of all of the processes in the system. Now, there is a reason why kernel actually does not have such knowledge, but it's not at all unreasonable to assume that the kernel has it.

matheusmoreira 1y ago
The thing that really blows minds is the fact Linux does not do name resolution at all. Getting rid of glibc breaks a lot of stuff because everyone depends on glibc to do it. https://wiki.archlinux.org/title/Domain_name_resolution https://wiki.archlinux.org/title/Domain_name_resolution https://en.wikipedia.org/wiki/Name_Service_Switch https://en.wikipedia.org/wiki/Name_Service_Switch https://man.archlinux.org/man/getaddrinfo.3 https://man.archlinux.org/man/getaddrinfo.3

dzaima 1y ago

That's not a truth that'd come from first principles, never mind a trivial truth; it's extremely trivial to imagine a kernel that does parse PATH where it wouldn't be true. As such, it's a thing one has to explicitly look up to know, which the author did.