5 ms·

> This is for example why you should avoid giving your files such cute names as '-rf'. The kernel should ban these names. I'm a big fan of dwheeler's proposal

> This is for example why you should avoid giving your files such cute names as '-rf'. The kernel should ban these names. I'm a big fan of dwheeler's proposal for fixing filenames: see http://www.dwheeler.com/essays/fixing-unix-linux-filenames.html http://www.dwheeler.com/essays/fixing-unix-linux-filenames.h... These is no god damn reason why a filename should be able to contain, say, LF, DEL, or BEL. None whatsoever.

hueving 10y ago
What? '-rf' is a specific set of flags for a specific program. You can't ban all possible flags for all programs in file names.
- quotemstr 10y ago
  Yes, programs are free to interpret arguments any way they want. (See dd(1).) But in practice, almost all programs interpret a leading dash in an argument word to mean "here be options". By banning filenames with leading dashes, we close a large number of security holes at minimal cost. Of course it's not a total solution, but from a pragmatic perspective, it's the right thing to do, because it goes a long way toward solving a real problem.
  - hueving 10y ago
    Close what security holes? If someone isn't escaping input they are still screwed if you ban dashes. It's like suggesting we don't allow sql to store quotes so we can use quotes to enclose data.
    - quotemstr 10y ago
      It's harm reduction. Yes, everyone should be escaping input. Yes, everyone should be using "./.foo" instead of just ".foo". But people don't, and they're not going to start. If we ban leading dashes, we stop these bugs from turning into security vulnerabilities. Your stance is like being against ASLR because developers just shouldn't have buffer overflow vulnerabilities in their code.
- kazinator 10y ago
  The operating system could address it by having a separate argument list and option list at the kernel level, creating an unambiguous interface for calling a program, giving it a list op options and non-option arguments. Ambiguity would remain in how a given shell parses input to determine what are options and what are arguments: but this would at least be out of the control of individual programs. Notably, the shell would be the tool which parses the -- convention. Programs wouldn't see the -- delimiter which separates options from non-options, so it would be impossible for a program to neglect to implement support for --.
kalleboo 10y ago
> These is no god damn reason why a filename should be able to contain, say, LF, DEL, or BEL. None whatsoever. OK you want ASCII 0x07 to be disallowed. Should a filename be allowed to contain "㜇"? (U+3707)
- kazinator 10y ago
  That's not a problem because the UTF-8 encoding of U+3707 will absolutely not contain any USASCII control characters, or any special shell or filesystem characters. It will all be bytes in the range 0x80-0xFF.
  - kalleboo 10y ago
    There are other encodings than UTF-8 though. Which is kind of my point. If you have your file system set to UTF-16 (doesn't NTFS do this?) then 0x07 will be present.
    - quotemstr 10y ago
      I also believe that filesystems should require that all filenames be fully normalized UTF-8. I don't think the benefits (slight, IMHO) of allowing filenames to be arbitrary byte strings outweigh the costs of code complexity and security problems.
- quotemstr 10y ago
  That's not how UTF-8 works.
  - kalleboo 10y ago
    It is how UTF-16 (NTFS) does though.
    - quotemstr 10y ago
      That doesn't count. Windows doesn't allow the 16-bit word 0x0007 to appear in filenames.
grymoire1 10y ago
Yes there is. You want the filesystem to be flexible. If the shell doesn't like those characters, use a different shell that doesn't care. It's brain-dead to create a filesystem that prevents flexibility in user interfaces.
- quotemstr 10y ago
  Flexibility is only a good thing if the benefits outweigh the costs. I insist that there are no legitimate (i.e., no better option) use cases for control characters in file names. The filesystem being "flexible" is not a good thing if flexibility causes real problems.

hueving 10y ago

What? '-rf' is a specific set of flags for a specific program. You can't ban all possible flags for all programs in file names.

quotemstr 10y ago
Yes, programs are free to interpret arguments any way they want. (See dd(1).) But in practice, almost all programs interpret a leading dash in an argument word to mean "here be options". By banning filenames with leading dashes, we close a large number of security holes at minimal cost. Of course it's not a total solution, but from a pragmatic perspective, it's the right thing to do, because it goes a long way toward solving a real problem.
- hueving 10y ago
  Close what security holes? If someone isn't escaping input they are still screwed if you ban dashes. It's like suggesting we don't allow sql to store quotes so we can use quotes to enclose data.
  - quotemstr 10y ago
    It's harm reduction. Yes, everyone should be escaping input. Yes, everyone should be using "./.foo" instead of just ".foo". But people don't, and they're not going to start. If we ban leading dashes, we stop these bugs from turning into security vulnerabilities. Your stance is like being against ASLR because developers just shouldn't have buffer overflow vulnerabilities in their code.
kazinator 10y ago
The operating system could address it by having a separate argument list and option list at the kernel level, creating an unambiguous interface for calling a program, giving it a list op options and non-option arguments. Ambiguity would remain in how a given shell parses input to determine what are options and what are arguments: but this would at least be out of the control of individual programs. Notably, the shell would be the tool which parses the -- convention. Programs wouldn't see the -- delimiter which separates options from non-options, so it would be impossible for a program to neglect to implement support for --.

kalleboo 10y ago

> These is no god damn reason why a filename should be able to contain, say, LF, DEL, or BEL. None whatsoever. OK you want ASCII 0x07 to be disallowed. Should a filename be allowed to contain "㜇"? (U+3707)

kazinator 10y ago
That's not a problem because the UTF-8 encoding of U+3707 will absolutely not contain any USASCII control characters, or any special shell or filesystem characters. It will all be bytes in the range 0x80-0xFF.
- kalleboo 10y ago
  There are other encodings than UTF-8 though. Which is kind of my point. If you have your file system set to UTF-16 (doesn't NTFS do this?) then 0x07 will be present.
  - quotemstr 10y ago
    I also believe that filesystems should require that all filenames be fully normalized UTF-8. I don't think the benefits (slight, IMHO) of allowing filenames to be arbitrary byte strings outweigh the costs of code complexity and security problems.
quotemstr 10y ago
That's not how UTF-8 works.
- kalleboo 10y ago
  It is how UTF-16 (NTFS) does though.
  - quotemstr 10y ago
    That doesn't count. Windows doesn't allow the 16-bit word 0x0007 to appear in filenames.

grymoire1 10y ago

Yes there is. You want the filesystem to be flexible. If the shell doesn't like those characters, use a different shell that doesn't care. It's brain-dead to create a filesystem that prevents flexibility in user interfaces.

quotemstr 10y ago
Flexibility is only a good thing if the benefits outweigh the costs. I insist that there are no legitimate (i.e., no better option) use cases for control characters in file names. The filesystem being "flexible" is not a good thing if flexibility causes real problems.