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

Why bother with argv[0]?

wietzebeukema.nl

Post reply on HN
Print view View original

241–250 of 277 posts

Re: Why bother with argv[0]?

#241

Post by blenderob »

immibis wrote: post #239
oguz-ismail wrote: post #125

Earlier quoted context omitted.

Shebangs are not part of the UNIX specification. What happens if an executable starts with `#!' is implementation-defined.

is being able to run busybox part of that specification? Linux ELF files are tagged for Linux OS, not generic Unix OS.

> is being able to run busybox part of that specification?

It's the other way round. This is like asking if running RHEL is part of the specification? Obviously not. But RHEL provides an environment that is quite close to the specification.

So is running a busybox part of the specification? Obviously not. But Busybox provides an environment that is close to the speficiation.

Re: Why bother with argv[0]?

#242

Post by johnisgood »

So wait, I should not use `argv` in C's main() or what?

Is it only speaking against `argv[0]` or `argv` in general?

What is this proposed solution if any?

What about `__progname`? The only issue here is that if `argv[0]` is a path, then `__progname` is only the filename. What if I want the path?

Re: Why bother with argv[0]?

#244

Post by sph »

What a silly post. I use argv[0] in my host-spawn tool (https://github.com/1player/host-spawn) so one can symlink it to a name inside a container and when you run it, it's executed on the host.

    # Inside your container:

    $ flatpak --version
    zsh: command not found: flatpak

    # Have host-spawn handle any flatpak command
    $ ln -s /usr/local/bin/host-spawn /usr/local/bin/flatpak

    # Now flatpak will always be executed on the host
    $ flatpak --version
    Flatpak 1.12.7
I am able to tell the symlink name by reading argv[0] to know which command to run. It is such a powerful and neat UNIX trick that has no simple alternative (in this example one would have to write ad-hoc shell scripts for each command they want to run)

Re: Why bother with argv[0]?

#245

Post by alkonaut »

travisgriggs wrote: post #32

> “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.

Really the weirdness isn't that main is invoked with the program name as argv[0]. The weirdness comes not in main() but in execv. Shouldn't execv have just taken the user provided arguments, prepended the program name (as provided by the OS) and then invoke the main function of the program with that array?

The busybox argument or shutdown/reboot explains why the name of a symlinked binary is helpful as argv[0]. But does the busybox/shutdown case explain why the execv lets the user set the argv[0] value to anything other than what the path says?

Re: Why bother with argv[0]?

#246

Post by 4star3star »

sph wrote: post #244

What a silly post. I use argv[0] in my host-spawn tool ( https://github.com/1player/host-spawn ) so one can symlink it to a name inside a container and when you run it, it's executed on the host. # Inside your container: $ flatpak --version zsh: command not found: flatpak # Have host-spawn handle any flatpak command $ ln -s /usr/local/bin/host-spawn /usr/local/bin/flatpak # Now flatpak will always be executed on the…

The post is silly because you wrote software that makes use of argv[0]? On the contrary, it opens a discussion about unintended security implications that might be avoided in the future if command line implementation can be reconsidered.

Re: Why bother with argv[0]?

#247

Post by thayne »

nrdvana wrote: post #207
gwbas1c wrote: post #142

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…

> it has been abused by external tools as a way to identify the program just because there was no other alternative.

There is an alternative, at least on linux: /proc/$pid/exe.

And if your question is "what executable is running" that is a better way to get it. But for a program like busybox, argv[0] is also important.

Re: Why bother with argv[0]?

#248

Post by shadowgovt »

gwbas1c wrote: post #142
yjftsjthsd-h wrote: post #44

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…

I see a common anti-pattern in security researchers in that they can lose sight of the human beings who operate the software.

argv[0] should be used by any logging message that purports to report the program name, because argv[0] should be a string the human recognizes as something they invoked. Taking it away would break usability.

This does, of course, imply that the program name is non-constant untrusted data. Which means we shouldn't be making security software that depends on knowing that name.

Re: Why bother with argv[0]?

#249

Post by rerdavies »

nrdvana wrote: post #207
gwbas1c wrote: post #142

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…

It's simply a case of "Do use argv[0] for this, and don't use it for THAT.

Both Windows and Linux provide APIs to get the actual path of the executable. Posix, to the best of my knowledge, does not. Regrettably. And the Linux API is, admittedly, a bit weird. But not that difficult really. Nothing that you can't get Claude to spit out for you in under 45 seconds. ;-P

The contents of argv[0] are yours to use and abuse as you see fit. Operating systems don't know or care if you go trampling recklessly through the contents of argv[0].

And the authors contention that "power --shutdown" and "power --reboot" are viable alternatives to "shutdown" and "reboot" seems.... disingenuous. Is the politest word I can come up with.

And, if you haven't asked yourself, "wait a second, what happens if somebody passes me garbage via execve" before you are halfway through writing the substantial amount of code required to portably normalize argv[0] to an executable path, I don't think you can be trusted to write secure code of any form. Just normalizing the various forms of argv[0] that a Linux shell passes you is a non-trivial effort. So don't use it for THAT.

Re: Why bother with argv[0]?

#250

Post by rpcope1 »

dcminter wrote: post #14

This lost me at "goes against modern design principles" without citing what principle(s) the author had in mind that would proscribe it.

Almost any time someone uses the words "legacy" or "modern" in the context of computers, it's a giveaway to me almost always someone has an axe to grind with few or no real deep substantive reasons. I typically read these as:

"legacy" -> anything that has existed for more than a day that I don't understand and don't like that stops me from poorly reinventing the wheel

"modern" -> anything that I dreamt up or heard some other hipster talk about recently that I got hyped about

Post reply on HN