Live data from Hacker News

Why bother with argv[0]?

wietzebeukema.nl

41–50 of 277 posts

Re: Why bother with argv[0]?

#41

This is why we can't have nice things. Security footguns everywhere! I'm fascinated by the intersection of argv[0], and the execve behavior of replacing the calling program with the called one. Aside from that, I quite like argv[0], for a much more limited set of reasons than considered in this interesting and comprehensive article. I like the ability to "retitle" a process to put a useful, descriptive, or branded na…

Your fascination is rewarded by reading the other man sections such as section three:

https://linux.die.net/man/3/execve

If you already know about the additional man pages beyond user space, i cannot more strongly recommend diving into them. Additionally the gnu 'info coreutils' is a good place to start, as well as the glibc manual.

Re: Why bother with argv[0]?

#42

I also use argv[0] for the -h help text, to show examples how to use the command.

I've done this too, but you should remove the path elements from the argv[0] string before you include it in your error/help messages.

You don't need to. Keeping them shows the user exactly how to call the program based on how they called it.

Re: Why bother with argv[0]?

#43
post #19

Earlier quoted context omitted.

On my system, these are hardlinks (regular files with a link count >1 and the same inode) rather than symlinks, though I'm not sure why.

Maybe to avoid broken links if you move the original files? That's the main benefit of hardlinks vs symlinks in my mind at least.

That can also be a downside, you believe you have moved stuff but now you can have different versions of programs that don't expect that to be a possibility.

Re: Why bother with argv[0]?

#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 system that populated it only from the actual file name and did not allow it to be written by the parent process or the child process at runtime. The obvious place this still falls apart is that an attacker could just

    ln /bin/curl ./some\ other\ name
but there are sometimes security measures that we use even though they're less than 100% effective so it at least conceivable that this might be a trade off worth making.

Re: Why bother with argv[0]?

#45
post #4

It is sometimes used to allow one binary to be the symlink target of hundreds of commands. Android does this for most common shell commands. Toybox and busybox are examples of such implementations. https://github.com/landley/toybox https://en.m.wikipedia.org/wiki/BusyBox

Also if you want a program to call itself, which is sometimes useful, this way lets you actually call the same program, rather than assuming the name and path.

There's no guarantee that the name and the path are still the same executable that is running, or that they even exist anymore.

Re: Why bother with argv[0]?

#47
post #7

> Today however, disk space is no longer considered an issue On desktop machines, perhaps, but this is certainly not true on all platforms Linux runs on.

Plus the whole "space is not an issue" thing along with "you can just add more ram" is the reason everything is so bloated and slow even on well provisioned machines.

Re: Why bother with argv[0]?

#48

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

One other historical reason for this (also the reason that older unix utilities tend to have such short names) is that people often interacted with unix machines over slow terminals or even paper teletypes. Typing "rm" instead of "remove" or "reboot" instead of "systemctl --reboot" was legitimately more convenient.

Re: Why bother with argv[0]?

#50

Also, on POSIX systems, exec-ing a program with argv[0] starting with ‘-‘ will have it start as a login shell, which is a whole rabbit hole of its own. I’m sure it’s within the security model (and the linked article doesn’t really discuss the concept of OS security models), but it’s still a pretty big shift in behaviour just from adding a character to the argv[0] value

No, that’s a property of how shells interpret argv[0], not a property of exec()
Post reply on HN