201–210 of 277 posts
> “Should a program be allowed to behave differently based on its name?” I don’t see why not. It’s allowed to behave differently based on the arguments that follow it. I personally think the genericity of including the program name itself as one of its own calling arguments is really meta cool.
So 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…
edit: basically login(1) execes your shell with - prepended, so an example where POSIX expects this
This is stupid. argv0 is just some data like any other data. It's ridiculously useful aside from the obvious busybox style usage. It's huge to be able to have a pointer to the directory where the executable resides, so you can package other assets along side it and have it all work for free without a seperate configuration file or env variables etc. Or for debugging or even non-error logging. You might call a binary…
Yes! I was surprised how far down I had to scroll to find somebody mentioning that one.
How else can you write a reasonably robust script that actually, you know, does something? You almost always need to grab some known files by their paths relative to the script.
I think argv[0] is fine. It sounds like there is a lot of bad security scanning software that doesn't understand how the `exec` syscall works. That sounds like their problem and not a fundamental problem with argv[0]. Most people use argv[0] so they can do something like: $ mycommand help Type `mycommand foo bar` to foo bars. $ mycommand1.2.3 help Type `mycommand1.2.3 foo bar` to foo bars. This is admittedly less fun…
Seems like this security software is broken, not argv[0]
Earlier quoted context omitted.
If it's a relative path, then changing the working directory will break (chdir("/") is a very common tactic at the top of main()). It's possible/desirable for the parent to change the PATH of a child process, particularly one that spawns other processes. So the argv[0] used to spawn the original process may be garbage for spawning children. Similarly in any kind of chroot jail (which may or may not be docker these da…
Hmm... I generally have so many issues with chdir (e.g. someone gives you a relative path to a file you need to read and now that's screwed up because you did a previous chdir) that I just avoid all use of it in the first place. Generally don't run into chroot all that often these days & docker gives you a fully virtualized environment where if a relative path is garbage then you may have other problems too (e.g. giv…
There's no way create a process such that /proc/self/exe is incorrect except if the process itself performs a chroot, or someone has overwritten what it points to. I'm talking about some other program running the process where those challenges don't show up.
> . And some software may be portable where argv[0] is a fine choice that works 90% of the time without worrying about maintaining a better solution on Linux
Except it's broken on MacOS and Windows, too!
I'm pretty confident saying that if you want to get the path to an executable, use the bespoke method for your platform because it ain't argv[0]. I have seen that codepath break so many times that there should just be a standard library method for it (and there often is, depending), and I have written this function at several companies.
There are not any edge cases that I'm aware of, except for a few esoteric ones. But there are quite a few edge cases for using argv[0], they exist on all platforms, and it's very annoying for people that have to fix or work around it because a software author didn't understand what argv[0] was.
So 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…
I agree, I think the author really shot themselves in the foot when they, at length, criticized the merits of a program using argv[0]. The real point are the security flaws in a calling program setting argv[0], because it really, really should be set by the operating system. (As a programmer, I shouldn't have to defend against these kinds of attacks. The OS should block it.) The criticisms of valid programming practi…
argv[0] was designed to be part of the arguments to the program, and it succeeds perfectly at that task. The problem is that it has been abused by external tools as a way to identify the program just because there was no other alternative.
It has to be writable because the entire argv string (in program memory) is writable and declared as
int main(int argc, char **argv)
int main(int argc, const char **argv)
Earlier quoted context omitted.
There's no guarantee that the name and the path are still the same executable that is running, or that they even exist anymore.
Unless you are on Windows
Earlier quoted context omitted.
I agree, I think the author really shot themselves in the foot when they, at length, criticized the merits of a program using argv[0]. The real point are the security flaws in a calling program setting argv[0], because it really, really should be set by the operating system. (As a programmer, I shouldn't have to defend against these kinds of attacks. The OS should block it.) The criticisms of valid programming practi…
The real security flaw is extracting a value from a process's own memory to identify what the process is. If you want a secure way to identify what a process is and where it came from, that needs to be a new feature in the OS. argv[0] was designed to be part of the arguments to the program, and it succeeds perfectly at that task. The problem is that it has been abused by external tools as a way to identify the progra…
How would that help? After all, even if this info comes from the OS, the decision logic still lives in your process's memory which the parent process still has full access to.
That's a weird take against argv[0] - all arguments are: "goes against modern design principles" and "can confuse programs which use argv[0] when they wanted "exec" instead" For the former, I don't see how this goes against modern principles - in presence of symlinks, it is pretty reasonable to want to know both "how was this program called", as well as "what's the actual executable we ended up with". And this does m…
And the key witness is systemd, which is too young to buy a beer - even in Germany.