3 ms·

> It is possible to workaround this, for example by pre pending "./". Or you could use the solutio9n provided by most argument parsers: the "--" option that di

by pdkl95 8y ago

> It is possible to workaround this, for example by pre pending "./". Or you could use the solutio9n provided by most argument parsers: the "--" option that disables option parsing for the remaining options. Trying to fix it yourself by "fixing" filenames (by prefixing with "./" or whatever) requires you to enumerate all possible problem[1] or you're just creating a new weird machine[2]. You're worrying a lot about specific problems like if a filename might be confused with an option, but there are many other ways filenames can be a problem *even if their names are limited to "simple"[3] alphanumeric characters. If you're accepting input from the user (or worse, over a network), you will have far worse problem than crashing on a bad filename if you aren't strictly validating and parsing that input before sending it to any other program or using it as a filename. [1] ("#2) Enumerating Badness") http://www.ranum.com/security/computer_security/editorials/dumb/ http://www.ranum.com/security/computer_security/editorials/d... [2] https://media.ccc.de/v/28c3-4763-en-the_science_of_insecurity https://media.ccc.de/v/28c3-4763-en-the_science_of_insecurit... [3] Defining concepts like "alphanumeric" or even "codepoints that can be safely [printed to the screen" are NOT simple co9ncepts if you support Unicode (which most programs should support).

pmoriarty 8y ago
The article addresses your suggestion: "The "obvious" way to do this is to litter command invocations with "--" before the filename(s). But it turns out this doesn't really work, because not all commands support "--" (ugh!). For example, the widely-used "echo" command is not required to support "--". What's worse, echo does support at least one dash option, so we need to escape leading-dash values somehow. POSIX recommends that you use printf(1) instead of echo(1), but some old systems do not include printf(1)."
- pdkl95 8y ago
  > But it turns out this doesn't really work, because not all commands support "--" So what? If you don't read the documentation for your the programs you run, mistaking filenames for an option is only only one of the many types of problem you might have. The problem of using programs incorrectly cannot be solved by changing filenames. You solve that type of problem by carefully understanding how to run each program you want to use (which means using -- for many (but not all) programs) and strictly validating & sanitizing your input.
  - faho 8y ago
    >The problem of using programs incorrectly cannot be solved by changing filenames If changing filenames makes an incorrect solution work, then it solves it, in that case. ---- In this thread, you're missing the point somewhat - the problem isn't that it's _impossible_ to work with all sorts of filenames using shell, the problem is that it's a PITA to do so, even for experienced users but especially for newbies. I.e. sure I can use `"$@"` everywhere and quote every single variable I ever use, and prefix every path with `./` or use `--` for every command that supports it. What if I didn't have to? Wouldn't that be better?
    - pdkl95 8y ago
      > In this thread, you're missing the point somewhat I assure you I'm not; I'm trying to explain why worrying about these problems at the filename level doesn't actually solve the problem, which should be handled at a different level of abstraction. > sure I can use `"$@"` everywhere and quote every single variable If you are writing Bourne shell without doing that, you are always going to have problems, because arguments are not always filenames. Yes, the syntax can be slightly annoying for historical/compatibility reasons. > What if I didn't have to? You don't. Use a different shell, or write your scripts in one of the many languages that are widely available like ruby, python, etc. If a scrip0t has #!/bin/sh at the top, you can probably rewrite it into any language you prefer.
- tedunangst 8y ago
  Which problem will be fixed first, all the systems you use will ship with printf(1) or all the systems you use will ban filenames starting with -?
dwheeler 8y ago
But you have already acknowledged the fundamental problem with using --, namely, that you cannot count on it always working. If you can't count on something, then that is not something you should be relying on. Clearly it is possible to do a lookup on every single command you ever use, but most people will not. Prepending "./" always works, no exceptions. I completely agree that validating input is very important. Indeed, I am recommending that the kernel do input validation on file names.
- anyfoo 8y ago
  It's important to validate input at the right level, otherwise you get attempts like PHP's "magic quotes" that appear to solve the problem superficially, but don't. I agree with others at this thread here: Each program that your program passes a filename to needs to be considered and handled individually. You cannot rely on "./" being a general solution. What if the program matches the given path against other paths, and does so verbatim without normalization? What if you're explicitly supposed to pass a filename, not a path? In the first case, maybe you claim that the program misbehaves, but one could argue that not having something like "--" is also misbehavior, and in any case, you have to handle it. Again: Thinking that there is a universal solution, like "./", for a problem that in reality is about inconsistent interfaces and therefore requires you to look at each interface individually will get you into hot waters.

by pdkl95 8y ago

pmoriarty 8y ago

The article addresses your suggestion: "The "obvious" way to do this is to litter command invocations with "--" before the filename(s). But it turns out this doesn't really work, because not all commands support "--" (ugh!). For example, the widely-used "echo" command is not required to support "--". What's worse, echo does support at least one dash option, so we need to escape leading-dash values somehow. POSIX recommends that you use printf(1) instead of echo(1), but some old systems do not include printf(1)."

pdkl95 8y ago
> But it turns out this doesn't really work, because not all commands support "--" So what? If you don't read the documentation for your the programs you run, mistaking filenames for an option is only only one of the many types of problem you might have. The problem of using programs incorrectly cannot be solved by changing filenames. You solve that type of problem by carefully understanding how to run each program you want to use (which means using -- for many (but not all) programs) and strictly validating & sanitizing your input.
- faho 8y ago
  >The problem of using programs incorrectly cannot be solved by changing filenames If changing filenames makes an incorrect solution work, then it solves it, in that case. ---- In this thread, you're missing the point somewhat - the problem isn't that it's _impossible_ to work with all sorts of filenames using shell, the problem is that it's a PITA to do so, even for experienced users but especially for newbies. I.e. sure I can use `"$@"` everywhere and quote every single variable I ever use, and prefix every path with `./` or use `--` for every command that supports it. What if I didn't have to? Wouldn't that be better?
  - pdkl95 8y ago
    > In this thread, you're missing the point somewhat I assure you I'm not; I'm trying to explain why worrying about these problems at the filename level doesn't actually solve the problem, which should be handled at a different level of abstraction. > sure I can use `"$@"` everywhere and quote every single variable If you are writing Bourne shell without doing that, you are always going to have problems, because arguments are not always filenames. Yes, the syntax can be slightly annoying for historical/compatibility reasons. > What if I didn't have to? You don't. Use a different shell, or write your scripts in one of the many languages that are widely available like ruby, python, etc. If a scrip0t has #!/bin/sh at the top, you can probably rewrite it into any language you prefer.
tedunangst 8y ago
Which problem will be fixed first, all the systems you use will ship with printf(1) or all the systems you use will ban filenames starting with -?

dwheeler 8y ago

But you have already acknowledged the fundamental problem with using --, namely, that you cannot count on it always working. If you can't count on something, then that is not something you should be relying on. Clearly it is possible to do a lookup on every single command you ever use, but most people will not. Prepending "./" always works, no exceptions. I completely agree that validating input is very important. Indeed, I am recommending that the kernel do input validation on file names.

anyfoo 8y ago
It's important to validate input at the right level, otherwise you get attempts like PHP's "magic quotes" that appear to solve the problem superficially, but don't. I agree with others at this thread here: Each program that your program passes a filename to needs to be considered and handled individually. You cannot rely on "./" being a general solution. What if the program matches the given path against other paths, and does so verbatim without normalization? What if you're explicitly supposed to pass a filename, not a path? In the first case, maybe you claim that the program misbehaves, but one could argue that not having something like "--" is also misbehavior, and in any case, you have to handle it. Again: Thinking that there is a universal solution, like "./", for a problem that in reality is about inconsistent interfaces and therefore requires you to look at each interface individually will get you into hot waters.