[deleted]
Why bother with argv[0]?
181–190 of 277 posts
Re: Why bother with argv[0]?
#182Earlier quoted context omitted.
I think you forget the exec system call’s first argument is a path to an executable, followed by an array of arguments, where arg[0] lives. I can’t find issue with exec(“/proc/self/exe”, [ program , … ).
Well, it could be for example that /proc is not mounted. A lot of software breaks for this, while really there is no need for it to be so. Also that approach only works on Linux, if you want to write a portable software what you do?
I am mainly pointing out that arg[0] is still valid. Writing portable software is an entirely different topic.
Re: Why bother with argv[0]?
#183Earlier quoted context omitted.
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.
This doesn't work. The eventual command would be /bin/busybox ls /path/to/ls/wrapper ...
Re: Why bother with argv[0]?
#184Earlier quoted context omitted.
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 "$@"`.
It can already do that, afaik. When I last checked, BusyBox supported installations via 4 methods: - symlink - hardlink - shell script wrappers - executable binary wrappers around libbusybox
Nice!
Re: Why bother with argv[0]?
#185I 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.
Sometimes you want it, sometimes you don't, so it needs to be in there, and sometimes you remove it yourself if your context of the moment doesn't want it.
And neither the want-it nor the don't-want-it case is such an outlier that you can disregard and not serve that case.
Sometimes you're talking to the user about general usage and the full path is a distracting detail and not the important part of the message.
Sometimes the full path and truthful invoked filename are an unnecessary security disclosure like telling a web viewer details about the server.
Sometimes the full path and truthful invoked filename is a necessary fact in debugging, or in errors, or even ordinary non-error logs that aren't public.
Re: Why bother with argv[0]?
#186Earlier quoted context omitted.
> Show the actual file path, and always an absolute one - that way you avoid confusion about which executable you're actually running, and it's just as readable if not more readable for every app _except_ those who care about argv[0], e.g. if you ran `/bin/dd` and it's actually busybox, in taskman you'd see `/bin/busybox` instead which'd be worse than seeing 'dd'. This was kind of in the middle of your complaint abou…
> On a unix filesystem, a file that's hard linked with multiple names has no single 'actual name' The same is true for hard linked files on Windows. That never stops Windows from showing you a path. There is almost always an "obviously right" path (the one used when opening the file). And if you lost track of that, deterministically choosing one of the possible paths is almost always more user friendly than just chow…
> There is almost always an "obviously right" path (the one used when opening the file).
The path used while opening a file is easy to get confused. If your cwd changed names or was deleted since you entered it, and you open an executable with a relative path, what is the "obviously right" path then?
Re: Why bother with argv[0]?
#187The author doesn't seem to understand that argv[0] can be different due to, for instance, one executable implementing many programs, such as BusyBox and similar projects.
While argv[0] is old, if you had to design it from scratch to day, it would still be a good idea to have the program invocation name as an argument.
The idea that anything old must is historic quirk that we can today eliminate is flawed.
Now argv[0] should not be relied upon for obtaining the executable name, except as a last resort if the program is built for platforms that don't have anything else. But if one executable has multiple program names via symlinks, only argv[0] will distinguish them.
Re: Why bother with argv[0]?
#188Earlier quoted context omitted.
What’s the issue with using argv[0] as a way to spawn yourself? I don’t recall running into a lot of issues.
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. given relative paths to files). You certainly have to be careful around chroot / docker anyway as I think resolving /proc/self/exe probably is dangerous too for all the same reasons and you need to be careful to use the literal "/proc/self/exe" string for the spawn command and also require that /proc is mounted and remember to pass through argv[0] unmolested (or mutating as needed depending on use-case).
There's enough corner cases that I'd hesitate given blanket advice as it requires knowing your actual execution environment to a degree that there's lots of valid choices that aren't outright "wrong". 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.
Re: Why bother with argv[0]?
#189This 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 from more than one place by other means than symlinks or hard links. You might be running from different mounted filsystems, chroot or container environments etc. A symlink might be in the middle of the path and not the executable name itself. Similarly a mount point.
It's just a random small useful tool like all others. Calling it some kind of security problem is like saying that screwdrivers are a security problem because aside from turning screws, some people can use screwdrivers to stab people, and we have nut drivers which can almost serve almost all the same needs for only a little extra work.
If your context of the moment means you have a security concern where you shouldn't trust this bit of data as gospel for some reason, then don't. Treat it like user input and take whatever precautions and fallback measures and sanity checks make sense for you in whatever particular situation you are in.
F-ing dumb.
Re: Why bother with argv[0]?
#190So 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]