This is near and dear to my heart. I wanted to make a utility to get the arguments of other processes, and found after looking that every single use of the KERN_PROCARGS2 sysctl (used on macOS) on the internet is wrong (they assume argv[0] is not an empty string), including Apple's and Google's. So after making my utility I also made a library out of it, both are bsd-3, but non-gratis: https://getargv.narzt.cam/
Why bother with argv[0]?
91–100 of 277 posts
Re: Why bother with argv[0]?
#92Re: Why bother with argv[0]?
#93So obviously claiming that there's no good reason for process to read argv[0] is either demonstrating the author's ignorance or needs a much stronger defense; I'd be fascinated to hear how they think busybox should work on an OpenWrt box with a 16MB root filesystem. However , I am willing to consider the discussion about whether there could be merit to restricting the ability to write that value; I could imagine a sy…
As the original author says (but seems to forget within a paragraph or two), the program should already know what program it is . If you're looking at argv to find out what program you are , you are doing it deeply wrong. It's an argument. One good use for it is to make a guess as to where your executable is installed. Yes, it would be nice if there were a more certain way to get that... but not for security purposes…
Am I missing something, you didn't seem to address the case where you actually need to know which program you are? The way busybox provides the whole suite of linux-utils in one binary and require the command under which it was invoked to know what to do.
Re: Why bother with argv[0]?
#94This is near and dear to my heart. I wanted to make a utility to get the arguments of other processes, and found after looking that every single use of the KERN_PROCARGS2 sysctl (used on macOS) on the internet is wrong (they assume argv[0] is not an empty string), including Apple's and Google's. So after making my utility I also made a library out of it, both are bsd-3, but non-gratis: https://getargv.narzt.cam/
On a related note, env vars do not have to be of the form key=value, they are arbitrary NUL-terminated byte strings just like the args.
Re: Why bother with argv[0]?
#95How about the part about knowing what the directory the executable was launched from? It could be different than the working directory.
Re: Why bother with argv[0]?
#96So obviously claiming that there's no good reason for process to read argv[0] is either demonstrating the author's ignorance or needs a much stronger defense; I'd be fascinated to hear how they think busybox should work on an OpenWrt box with a 16MB root filesystem. However , I am willing to consider the discussion about whether there could be merit to restricting the ability to write that value; I could imagine a sy…
As the original author says (but seems to forget within a paragraph or two), the program should already know what program it is . If you're looking at argv to find out what program you are , you are doing it deeply wrong. It's an argument. One good use for it is to make a guess as to where your executable is installed. Yes, it would be nice if there were a more certain way to get that... but not for security purposes…
[deleted]
Re: Why bother with argv[0]?
#97Earlier quoted context omitted.
That seems unnecessarily harsh. I don't think that's the gist of the article, but the throwaway suggestion of 'just make lots of copies, who cares about diskspace' is insufficient and thus distracts. It's.. a single line about solutions in an article that isn't _about_ solving problems, it's about highlighting a problem exists and that it's worth solving. I read the article more as: There is __often__ no good reason…
There's the `setproctitle` in FreeBSD that is designed exactly for a process to update the information that is presented to tools such as ps. https://man.freebsd.org/cgi/man.cgi?query=setproctitle&aprop...
There's also getprogname(3) on a lot of systems, and the __progname variable. I seem to recall this is an area where various Unix like systems have slight variations.
Re: Why bother with argv[0]?
#98Earlier quoted context omitted.
As the original author says (but seems to forget within a paragraph or two), the program should already know what program it is . If you're looking at argv to find out what program you are , you are doing it deeply wrong. It's an argument. One good use for it is to make a guess as to where your executable is installed. Yes, it would be nice if there were a more certain way to get that... but not for security purposes…
Am I missing something, you didn't seem to address the case where you actually need to know which program you are? The way busybox provides the whole suite of linux-utils in one binary and require the command under which it was invoked to know what to do.
Busybox still knows that it's busybox, and it is using that argument to decide which of its many functions to execute.
This person is arguing that that's somehow wrong because busybox, or more importantly some other software that's trying to monitor it, might get confused about whether it's busybox.
Re: Why bother with argv[0]?
#99So obviously claiming that there's no good reason for process to read argv[0] is either demonstrating the author's ignorance or needs a much stronger defense; I'd be fascinated to hear how they think busybox should work on an OpenWrt box with a 16MB root filesystem. However , I am willing to consider the discussion about whether there could be merit to restricting the ability to write that value; I could imagine a sy…
[deleted]
Re: Why bother with argv[0]?
#100So obviously claiming that there's no good reason for process to read argv[0] is either demonstrating the author's ignorance or needs a much stronger defense; I'd be fascinated to hear how they think busybox should work on an OpenWrt box with a 16MB root filesystem. However , I am willing to consider the discussion about whether there could be merit to restricting the ability to write that value; I could imagine a sy…
Restricting setting it would break login. Not that it couldn't be fixed by changing how we handle login shells but still. Worth remembering. Similarly the busybox situation could be solved by having busybox ship posix shell wrapper scripts which use `#!/bin/busybox sh` as the shebang and simply consist of a line like `exec /bin/busybox ls "$@"`.
You are over-complicating it, you only need `#!/bin/busybox ls` as the entire contents of the file.