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

221–230 of 277 posts

Re: Why bother with argv[0]?

#221

Post by kelnos »

rzwitserloot wrote: post #58
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…

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…

> it's about highlighting a problem exists and that it's worth solving.

If so, then I disagree with the premise of the article, fundamentally. I don't see a problem. If someone is writing security software and doesn't already know about the mutability of argv[0], and doesn't know that (on Linux at least) /proc/$PID/exe is the only correct way to gt the binary backing a process... well, then they have no business writing security software.

There is no problem here. The author is making a big deal about nothing, either because they have a weird axe to grind, or because they're ignorant.

Re: Why bother with argv[0]?

#222

Post by kelnos »

toast0 wrote: post #186
wongarsu wrote: post #167

Earlier quoted context omitted.

> 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?

I don't think that really follows. If the OS wants to track this, it should canonicalize the path to the executable on startup, and then stash it somewhere.

(And a program could do that itself, if it wants to.)

Re: Why bother with argv[0]?

#223

Post by anacrolix »

I think the Unix philosophy wins here. It might not be a clean interface but let the implementations decide what to do with it. If you remove it you are more likely to cause issues and have to grow new interfaces elsewhere.

Re: Why bother with argv[0]?

#224

Post by [deleted] »

vlovich123 wrote: post #164
alerighi wrote: post #151

Earlier quoted context omitted.

Well that would be inefficient. For each command you run the kernel has to read the file, detect that it has a shebang, parse the shebang line, and then finally load the actual executable in memory. That could be a performance problem, since busybox is used typically in embedded systems that doesn't have a lot of resources: imagine a shell script that runs a command in a loop, it has to do a lot of extra work. Finall…

I’m going to challenge you on the performance angle. Instead of doing the shebang line, it has to traverse the filesystem to resolve the link. I suspect that’s probably more expensive than parsing the shebang line. Indeed, a shell script that runs a command in a loop should have busybox detecting the built in command & executing it inline without spawning executables via the file system (this is common in bash as wel…

[deleted]

Re: Why bother with argv[0]?

#225

Post by gwbas1c »

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…

Take a closer look at the exploits listed, they all have to do with malware manipulating argv[0] when creating a new process; not with a process manipulating argv after it starts.

There is no mention of mutable memory attacks.

(If I was on a computer I'd fire up a C IDE to even see what happens when I mutate argv. I suspect the OS keeps its own copy of what the process was started with.)

Re: Why bother with argv[0]?

#226

Post by [deleted] »

kelnos wrote: post #220
cxr wrote: post #170

Earlier quoted context omitted.

> Well that would be inefficient. For each command you run the kernel has to read the file, detect that it has a shebang, parse the shebang line, and then finally load the actual executable in memory. Those that exist today would, but no kernel would have to work like that. Once you've agreed that monolithic kernels have merits, you've accepted that the kernel can do whatever it wants to make this efficient—including…

> Those that exist today would, but no kernel would have to work like that. That's a pretty weird argument. "Yes, what you say is completely correct, but let's imagine a world where you were wrong." We have what we have, today. We should form conclusions and make decisions based on things that exist, not on things that we might dream up.

[deleted]

Re: Why bother with argv[0]?

#227

Post by theamk »

duped wrote: post #180
vlovich123 wrote: post #165

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

yesh, that's why my post literally said, "A lot of times you know you never called chdir()..."

Sure, don't put this in the library, but there is nothing wrong with using it in the app where you know no one makes this call.

Re: Why bother with argv[0]?

#228

Post by [deleted] »

kelnos wrote: post #220
cxr wrote: post #170

Earlier quoted context omitted.

> Well that would be inefficient. For each command you run the kernel has to read the file, detect that it has a shebang, parse the shebang line, and then finally load the actual executable in memory. Those that exist today would, but no kernel would have to work like that. Once you've agreed that monolithic kernels have merits, you've accepted that the kernel can do whatever it wants to make this efficient—including…

> Those that exist today would, but no kernel would have to work like that. That's a pretty weird argument. "Yes, what you say is completely correct, but let's imagine a world where you were wrong." We have what we have, today. We should form conclusions and make decisions based on things that exist, not on things that we might dream up.

[deleted]

Re: Why bother with argv[0]?

#229

Post by cxr »

kelnos wrote: post #220
cxr wrote: post #170

Earlier quoted context omitted.

> Well that would be inefficient. For each command you run the kernel has to read the file, detect that it has a shebang, parse the shebang line, and then finally load the actual executable in memory. Those that exist today would, but no kernel would have to work like that. Once you've agreed that monolithic kernels have merits, you've accepted that the kernel can do whatever it wants to make this efficient—including…

> Those that exist today would, but no kernel would have to work like that. That's a pretty weird argument. "Yes, what you say is completely correct, but let's imagine a world where you were wrong." We have what we have, today. We should form conclusions and make decisions based on things that exist, not on things that we might dream up.

[flagged]

Re: Why bother with argv[0]?

#230

Post by jolmg »

cxr wrote: post #229
kelnos wrote: post #220

Earlier quoted context omitted.

> Those that exist today would, but no kernel would have to work like that. That's a pretty weird argument. "Yes, what you say is completely correct, but let's imagine a world where you were wrong." We have what we have, today. We should form conclusions and make decisions based on things that exist, not on things that we might dream up.

[flagged]

> it's against the rules here to those kinds of fake quotes.

What part of the guidelines are you referring to?

Also, despite the quotation marks, I don't think they mean to quote you. They're just rephrasing you as they understood you.

Coincidentally enough, I've just done that too in another comment:

https://news.ycombinator.com/item?id=41442007

Post reply on HN