5 ms·

> This vulnerability affects platforms with case-insensitive filesystems... What kind of platforms use case-insensitive filesystems?

by jolmg 6y ago

Operyl 6y ago
macOS, to name one. It appears NTFS is also vulnerable according to the posting.
- pcthrowaway 6y ago
  Ashamed to admit (as an OSX user) that I didn't even realize the FS was case-insensitive (having migrated from years of Linux usage to a non-Linux desktop). It does a good job of hiding this from the user (filenames are still listed with cases, and bash autocompletion completes to the correct case as well)
  - caymanjim 6y ago
    MacOS by default uses a "case-preserving case-insensitive" filesystem, so you can create files with mixed case, but you can't create two files with the same name and different case. It's one of MacOS's more-egregious crimes against Unix. Fortunately it doesn't manifest that often, but it rears its head often enough to be a problem.
    - deleted 6y ago
      [deleted]
    - leephillips 6y ago
      It may be a crime, but is the result of a set of compromises in the design of the OSX filesystem, which had to work with a BSD variant while also being compatible with pre-OSX days. I think it’s one thing they actually did an elegant job with. EDIT: This document describes some of the challenges: https://www.usenix.org/legacy/publications/library/proceedings/usenix2000/invitedtalks/sanchez_html/sanchez.html https://www.usenix.org/legacy/publications/library/proceedin...
      - EamonnMR 6y ago
        This is the first article I've found that does a decent job of explaining what a resource fork really is.
    - _jal 6y ago
      > It's one of MacOS's more-egregious crimes against Unix. Nah. Using a file system means putting up with its semantics. HFS+ was case-insensitive; they were deploying an upgrade to millions of existing filesystems. If you mount, say, an NFS volume, MacOS does the expected thing.
    - ComputerGuru 6y ago
      That’s the same as Windows, but Windows enables making directories case sensitive on a directory by directory basis.
    - Ancapistani 6y ago
      > Fortunately it doesn't manifest that often, but it rears its head often enough to be a problem. IIRC, one place where it does rear its head in when a file is renamed in a git commit to a value that downcases to the same value as the prior name. For example `Foo.txt`->`foo.txt`. I have `core.ignorecase = true` in my `.gitconfig` for this very reason.
      - geofft 6y ago
        The extraordinarily frustrating case is where you're working on a repository that has multiple files that differ only by case. Git will check out one of them, then overwrite it with the other. The Linux kernel is one of them: several of the headers that get installed to /usr/include/linux/netfilter have conflicts on a case-insensitive filesystem. https://github.com/torvalds/linux/tree/master/include/uapi/linux/netfilter https://github.com/torvalds/linux/tree/master/include/uapi/l... Debhelper used to be one of those until I convinced them to change it: they had a Debian/ directory for the Perl module Debian::Debhelper as well as a debian/ directory for the packaging metadata. https://bugs.debian.org/873043 https://bugs.debian.org/873043 (I suspect I'm a little unusual in wanting to have checkouts of Linux and Debhelper on my Mac homedir.)
    - dreamcompiler 6y ago
      The fact that Linux is case-sensitive is the egregious crime. It's a nasty holdover from circa-1970 Unix when case-folding was an expensive operation.
      - akersten 6y ago
        Case-senitivity is not a "nasty holdover", it is a good design decision that continues to be proven correct (case in point, this bugfix for case-insensitive filesystems). Why would you introduce complexity into the filesystem to try to normalize file names when you can simply, not? I mean, have you _seen_ the mess that is Unicode normalization? Hundreds of different glyphs or whatever that are all considered equivalent, but are actually composed of different bytes. The filesystem should try to make sense of all that, and consider them equivalent paths? Even if you say "well, just capitalization, not Unicode normalization," there's the whole German letter ẞ => ss (or is it ß?) and similar friends like the Turkish dotted I that have popped up as articles on HN. Absolutely glad Linux filesystems by and large do not attempt to take that on, and treat paths as a bucket of bytes instead. All for what benefit - so you can type File.txt in the terminal and have the OS find file.txt? That is much more appropriate for the Application layer to resolve, rather than the filesystem. Bugs like this come from over-engineering. Filesystems should be simple, and follow the principle of least surprise.
        dreamcompiler 6y ago
        It bugs me to see foo.c and Foo.c as separate files in a directory listing. I like the fact that MacOS doesn't allow this situation to ever happen. Not taking on that problem means it's left to the user to figure out what's going on when similar glyphs occur.
    - shp0ngle 6y ago
      wasn't this fixed with their new Apple FS? Wait I'll try ...nope, after `touch makefile` and `touch Makefile`, I still see just `makefile`. OK
  - deleted 6y ago
    [deleted]
  - oars 6y ago
    I'm in the same boat - used MacOS for the past 6 years, including the terminal nearly everyday! :d
  - Cloudef 6y ago
    OSX has even more annoying problem that it decomposes unicode: https://stackoverflow.com/questions/5581857/git-and-the-umlaut-problem-on-mac-os-x https://stackoverflow.com/questions/5581857/git-and-the-umla... Many fun times trying to copy/move/remove a file and not being able to do so because the input and name stored on fs is actually different bytewise... Seems like linux has the only sane filesystems not trying to mangle paths at all.
    - jrochkind1 6y ago
      If linux doesn't normalize unicode at all, can you have two different files that look like they are named `josé`, depending on if the é is decomposed or not?
      - chungy 6y ago
        If you use a file system that doesn't normalize lookups, yes you can.
      - Cloudef 6y ago
        Yes, for linux filenames are just bytes. Apart from / and NUL characters it doesnt care what you give it, nor does it mangle them anyway, its the only sane thing to do.
        Someone 6y ago
        The only sane thing to do if you don’t care about how humans (as opposed to nerds) think. In the end, the file system doesn’t exist in isolation, it is there to support users, and most of them won’t care how many bytes “é” takes to store. Unix, by not even defining the way to interpret the bytes of file names (one can’t even assume that names consisting of only bytes that correspond to ASCII letters and digits should be interpreted as ASCII) makes it impossible to show file names to users. That’s insane.
        jolmg 6y ago
        > The only sane thing to do if you don’t care about how humans (as opposed to nerds) think. At the FS layer, I think that's better. Makes things simpler for programs. For non-techie humans, unicode can be normalized at upper levels, like the GUI file manager or toolkit library that does save dialogs, etc. That's if humans being confused because of lack of normalization of unicode is a real practical issue and not just something that can happen but never does.
- jnwatson 6y ago
  FYI, on MacOS, it is a property of the partition, so you can reformat and have a case-sensitive filesystem. Applications may subtly break if they weren't tested on such a filesystem, but I had used one for several years without too many issues.
  - jamesog 6y ago
    Since the introduction of APFS I've taken to creating a new APFS volume formatted as case-sensitive, and put my git repositories there. This has mostly been useful for working on shared repositories where, say, a Linux user (or other user on a case-sensitive filesystem) pushes two branches, say `feature/foo` and `feature/Foo` which works fine for them, but on a case-insensitive filesystem, git gets very upset.
- jameshart 6y ago
  Once spent way longer than I would have liked trying to debug an iOS app issue that couldn’t reproduce and debug in the emulator because iOS devices have a case-sensitive FS, macOS devices typically don’t, and the emulator was subject to the macOS file system’s conventions. Leaky abstractions all the way down.
deleted 6y ago
[deleted]
rhinoceraptor 6y ago
MacOS and Windows
- jolmg 6y ago
  I guess it shows that I haven't really used either of those in a long time.
  - Jtsummers 6y ago
    macOS has defaulted to be case insensitive largely due to historical and perhaps usability reasons. You can opt to make it case sensitive (and I do, which broke Steam for several years but that also freed my time).
    - emodendroket 6y ago
      When necessary you can make an auto-expanding volume that's case-sensitive and leave your host FS alone. I have not found that I really want to have differently-cased but otherwise identical filenames in the real world at any point though.
      - dhosek 6y ago
        Ages ago, I heard from co-workers at a company that I had left that there was an issue because of some file-naming in a PHP application that they were trying to run locally on a Mac. There was foo.php which was the interface and Foo.php which had a class definition in it. What idiot would name files like that? I said. You, they answered. I don't do that sort of thing anymore.
      - earthboundkid 6y ago
        A bug that affects my teams once every few years is a developer will create a file named "A.txt" check it into Git, realize it should be "a.txt" and rename it, and then basically everything will shit the bed and you waste a day figuring out why nothing is working. A related bug is a developer will make a webpage called /a/ but link to /A/ and then the link will be broken in production. At this point, I have seen this same bug enough times to be able to fix it reasonably quickly, but it definitely wastes time for the team.
deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
zo1 6y ago
Windows. Its a notable problem with git + Windows that has gotten better over time but still leads to a lot of WTF moments. For many this event is the first time they hear that window's filesystem is case insensitive.
- rightbyte 6y ago
  It is strange I haven't noticed earlier. Maybe it is just so unnatural to name files the same with different cases that I haven't tried.
- swiley 6y ago
  Sometimes it feels like corporate IT creates more security problems than it solves: windows as development machines, solar winds, Fucking McAffee malware on everything.
Foxboron 6y ago
Linux these days actually. You can make ext4 case insesitive. https://www.collabora.com/news-and-blog/blog/2020/08/27/using-the-linux-kernel-case-insensitive-feature-in-ext4/ https://www.collabora.com/news-and-blog/blog/2020/08/27/usin... Note: I also learned this today. Had no clue.
- suifbwish 6y ago
  Why the heck would anyone want that? That’s arguably worse than adding spaces in file names
chungy 6y ago
ZFS has a case-insensitive option.

> This vulnerability affects platforms with case-insensitive filesystems... What kind of platforms use case-insensitive filesystems?

by jolmg 6y ago

> This vulnerability affects platforms with case-insensitive filesystems... What kind of platforms use case-insensitive filesystems?

Operyl 6y ago

macOS, to name one. It appears NTFS is also vulnerable according to the posting.

pcthrowaway 6y ago
Ashamed to admit (as an OSX user) that I didn't even realize the FS was case-insensitive (having migrated from years of Linux usage to a non-Linux desktop). It does a good job of hiding this from the user (filenames are still listed with cases, and bash autocompletion completes to the correct case as well)
- caymanjim 6y ago
  MacOS by default uses a "case-preserving case-insensitive" filesystem, so you can create files with mixed case, but you can't create two files with the same name and different case. It's one of MacOS's more-egregious crimes against Unix. Fortunately it doesn't manifest that often, but it rears its head often enough to be a problem.
  - deleted 6y ago
    [deleted]
  - leephillips 6y ago
    It may be a crime, but is the result of a set of compromises in the design of the OSX filesystem, which had to work with a BSD variant while also being compatible with pre-OSX days. I think it’s one thing they actually did an elegant job with. EDIT: This document describes some of the challenges: https://www.usenix.org/legacy/publications/library/proceedings/usenix2000/invitedtalks/sanchez_html/sanchez.html https://www.usenix.org/legacy/publications/library/proceedin...
    - EamonnMR 6y ago
      This is the first article I've found that does a decent job of explaining what a resource fork really is.
  - _jal 6y ago
    > It's one of MacOS's more-egregious crimes against Unix. Nah. Using a file system means putting up with its semantics. HFS+ was case-insensitive; they were deploying an upgrade to millions of existing filesystems. If you mount, say, an NFS volume, MacOS does the expected thing.
  - ComputerGuru 6y ago
    That’s the same as Windows, but Windows enables making directories case sensitive on a directory by directory basis.
  - Ancapistani 6y ago
    > Fortunately it doesn't manifest that often, but it rears its head often enough to be a problem. IIRC, one place where it does rear its head in when a file is renamed in a git commit to a value that downcases to the same value as the prior name. For example `Foo.txt`->`foo.txt`. I have `core.ignorecase = true` in my `.gitconfig` for this very reason.
    - geofft 6y ago
      The extraordinarily frustrating case is where you're working on a repository that has multiple files that differ only by case. Git will check out one of them, then overwrite it with the other. The Linux kernel is one of them: several of the headers that get installed to /usr/include/linux/netfilter have conflicts on a case-insensitive filesystem. https://github.com/torvalds/linux/tree/master/include/uapi/linux/netfilter https://github.com/torvalds/linux/tree/master/include/uapi/l... Debhelper used to be one of those until I convinced them to change it: they had a Debian/ directory for the Perl module Debian::Debhelper as well as a debian/ directory for the packaging metadata. https://bugs.debian.org/873043 https://bugs.debian.org/873043 (I suspect I'm a little unusual in wanting to have checkouts of Linux and Debhelper on my Mac homedir.)
  - dreamcompiler 6y ago
    The fact that Linux is case-sensitive is the egregious crime. It's a nasty holdover from circa-1970 Unix when case-folding was an expensive operation.
    - akersten 6y ago
      Case-senitivity is not a "nasty holdover", it is a good design decision that continues to be proven correct (case in point, this bugfix for case-insensitive filesystems). Why would you introduce complexity into the filesystem to try to normalize file names when you can simply, not? I mean, have you _seen_ the mess that is Unicode normalization? Hundreds of different glyphs or whatever that are all considered equivalent, but are actually composed of different bytes. The filesystem should try to make sense of all that, and consider them equivalent paths? Even if you say "well, just capitalization, not Unicode normalization," there's the whole German letter ẞ => ss (or is it ß?) and similar friends like the Turkish dotted I that have popped up as articles on HN. Absolutely glad Linux filesystems by and large do not attempt to take that on, and treat paths as a bucket of bytes instead. All for what benefit - so you can type File.txt in the terminal and have the OS find file.txt? That is much more appropriate for the Application layer to resolve, rather than the filesystem. Bugs like this come from over-engineering. Filesystems should be simple, and follow the principle of least surprise.
      - dreamcompiler 6y ago
        It bugs me to see foo.c and Foo.c as separate files in a directory listing. I like the fact that MacOS doesn't allow this situation to ever happen. Not taking on that problem means it's left to the user to figure out what's going on when similar glyphs occur.
  - shp0ngle 6y ago
    wasn't this fixed with their new Apple FS? Wait I'll try ...nope, after `touch makefile` and `touch Makefile`, I still see just `makefile`. OK
- deleted 6y ago
  [deleted]
- oars 6y ago
  I'm in the same boat - used MacOS for the past 6 years, including the terminal nearly everyday! :d
- Cloudef 6y ago
  OSX has even more annoying problem that it decomposes unicode: https://stackoverflow.com/questions/5581857/git-and-the-umlaut-problem-on-mac-os-x https://stackoverflow.com/questions/5581857/git-and-the-umla... Many fun times trying to copy/move/remove a file and not being able to do so because the input and name stored on fs is actually different bytewise... Seems like linux has the only sane filesystems not trying to mangle paths at all.
  - jrochkind1 6y ago
    If linux doesn't normalize unicode at all, can you have two different files that look like they are named `josé`, depending on if the é is decomposed or not?
    - chungy 6y ago
      If you use a file system that doesn't normalize lookups, yes you can.
    - Cloudef 6y ago
      Yes, for linux filenames are just bytes. Apart from / and NUL characters it doesnt care what you give it, nor does it mangle them anyway, its the only sane thing to do.
      - Someone 6y ago
        The only sane thing to do if you don’t care about how humans (as opposed to nerds) think. In the end, the file system doesn’t exist in isolation, it is there to support users, and most of them won’t care how many bytes “é” takes to store. Unix, by not even defining the way to interpret the bytes of file names (one can’t even assume that names consisting of only bytes that correspond to ASCII letters and digits should be interpreted as ASCII) makes it impossible to show file names to users. That’s insane.
        jolmg 6y ago
        > The only sane thing to do if you don’t care about how humans (as opposed to nerds) think. At the FS layer, I think that's better. Makes things simpler for programs. For non-techie humans, unicode can be normalized at upper levels, like the GUI file manager or toolkit library that does save dialogs, etc. That's if humans being confused because of lack of normalization of unicode is a real practical issue and not just something that can happen but never does.
jnwatson 6y ago
FYI, on MacOS, it is a property of the partition, so you can reformat and have a case-sensitive filesystem. Applications may subtly break if they weren't tested on such a filesystem, but I had used one for several years without too many issues.
- jamesog 6y ago
  Since the introduction of APFS I've taken to creating a new APFS volume formatted as case-sensitive, and put my git repositories there. This has mostly been useful for working on shared repositories where, say, a Linux user (or other user on a case-sensitive filesystem) pushes two branches, say `feature/foo` and `feature/Foo` which works fine for them, but on a case-insensitive filesystem, git gets very upset.
jameshart 6y ago
Once spent way longer than I would have liked trying to debug an iOS app issue that couldn’t reproduce and debug in the emulator because iOS devices have a case-sensitive FS, macOS devices typically don’t, and the emulator was subject to the macOS file system’s conventions. Leaky abstractions all the way down.

deleted 6y ago

[deleted]

rhinoceraptor 6y ago

MacOS and Windows

jolmg 6y ago
I guess it shows that I haven't really used either of those in a long time.
- Jtsummers 6y ago
  macOS has defaulted to be case insensitive largely due to historical and perhaps usability reasons. You can opt to make it case sensitive (and I do, which broke Steam for several years but that also freed my time).
  - emodendroket 6y ago
    When necessary you can make an auto-expanding volume that's case-sensitive and leave your host FS alone. I have not found that I really want to have differently-cased but otherwise identical filenames in the real world at any point though.
    - dhosek 6y ago
      Ages ago, I heard from co-workers at a company that I had left that there was an issue because of some file-naming in a PHP application that they were trying to run locally on a Mac. There was foo.php which was the interface and Foo.php which had a class definition in it. What idiot would name files like that? I said. You, they answered. I don't do that sort of thing anymore.
    - earthboundkid 6y ago
      A bug that affects my teams once every few years is a developer will create a file named "A.txt" check it into Git, realize it should be "a.txt" and rename it, and then basically everything will shit the bed and you waste a day figuring out why nothing is working. A related bug is a developer will make a webpage called /a/ but link to /A/ and then the link will be broken in production. At this point, I have seen this same bug enough times to be able to fix it reasonably quickly, but it definitely wastes time for the team.

deleted 6y ago

[deleted]

deleted 6y ago

[deleted]

zo1 6y ago

Windows. Its a notable problem with git + Windows that has gotten better over time but still leads to a lot of WTF moments. For many this event is the first time they hear that window's filesystem is case insensitive.

rightbyte 6y ago
It is strange I haven't noticed earlier. Maybe it is just so unnatural to name files the same with different cases that I haven't tried.
swiley 6y ago
Sometimes it feels like corporate IT creates more security problems than it solves: windows as development machines, solar winds, Fucking McAffee malware on everything.

Foxboron 6y ago

Linux these days actually. You can make ext4 case insesitive. https://www.collabora.com/news-and-blog/blog/2020/08/27/using-the-linux-kernel-case-insensitive-feature-in-ext4/ https://www.collabora.com/news-and-blog/blog/2020/08/27/usin... Note: I also learned this today. Had no clue.

suifbwish 6y ago
Why the heck would anyone want that? That’s arguably worse than adding spaces in file names

chungy 6y ago

ZFS has a case-insensitive option.