8 ms·

Filesystem hierarchy standard (2013)

46 points by nivethan 4y ago

jmclnx 4y ago
Too bad the major Linux Distros tossed this out the window years ago.
- isabellat 4y ago
  What in particular are you referring to? A lot of software still depends on paths that adhere to the FHS. Dynamic linkers, etc all bake in assumptions about search paths based on FHS. Certainly application developers will violate FHS when placing config files etc but I’m curious what the Distros are tossing out?
- ElectricalUnion 4y ago
  The only "major Linux Distro" that I know that actually doesn't follow FHS is NixOS, and even NixOS has FHS-compatible overlay options for handling proprietary/pre-compiled software.
- egberts1 4y ago
  Ummm, there is a general acceptance of a newer version of LFS, version 3. If version mistaken, you must be thinking of just two distros. - NixOS, like totally tossed LFSv3 out, 100% - RedHat/Fedora, they are smushing both /bin and /usr/bin together. This breaks any link with embedded world (and will come back to bite them when Intel ME becomes abandonware due to malware pervasiveness and their inability to keep those out.
  - egberts1 4y ago
    A tiny smatters of Linux distro are smushing both /tmp and /var/tmp. That one is never a good idea, not even in production servers nor embedded world. /tmp gets emptied with each reboot. /var/tmp is about surviving across reboot. But the app would run just fine if it were ever to be emptied. # Alternatively Some have said that /var/cache would be the more appropriate use over /var/tmp. But /var/cache is used for daemon cold restart and reconstruction of internal structures after reboot, restart, reload, or worse, Ethernet cable disconnect under only systemd-networkd (daemon gets killed by systemd). Your prized networked daemon falls into this category. /var/tmp is generally for session-specific (that are expected to survive across reboot) as opposed to daemon’s internal structure. ISC DHCP client is one.
  - packetlost 4y ago
    > This breaks any link with embedded world (and will come back to bite them when Intel ME becomes abandonware due to malware pervasiveness and their inability to keep those out. Can you expand on that? What does /usr/bin have to do with embedded systems programming??
    - egberts1 4y ago
      Glad you ask. In a really, really secured Unix environment, the /bin is typically a read-only partition. In a secured embedded world, this would be a separate flash hardware chip whose read-write is controlled by a hardware switch. Busybox would encompass most of the entries under /bin but it is often that package management must negotiate out-of-band with admin doing upgrades when using bigger “busybox” like GNU utils. Intel ME and its storage of binary blob has been problematic of defying clean delineation of nested security boundary, notably when TPM is not covering Intel ME to a point of Intel making another stab at TPM. So where do you put the upgrades for Intel Management Engine? This paper indirectly covers Intel’s future plan of dealing with these shortcomings. https://www.intel.com/content/dam/www/public/us/en/security-advisory/documents/intel-csme-security-white-paper.pdf https://www.intel.com/content/dam/www/public/us/en/security-... Today’s fight is about making these partitions as easy to upgrade as possible (for /bin.). My assertion is that remote upgrade^H^H^H^H^H^Hrecovery should never be a possibility when your /bin code has been thoroughly vetted and secured.
      - ElectricalUnion 4y ago
        > In a really, really secured Unix environment, the /bin is typically a read-only partition. > In a secured embedded world, this would be a separate flash hardware chip whose read-write is controlled by a hardware switch. I fail to see how this is secure without also securing /etc (PATH, LD_LIBRARY_PATH), /lib, /usr/lib, /usr/bin, /usr/local/bin - and at this point, might as well make the whole root mount thing RO and have a separated block device for the RW parts instead. > Intel ME and its storage of binary blob has been problematic of defying clean delineation of nested security boundary, notably when TPM is not covering Intel ME to a point of Intel making another stab at TPM. Intel ME is _trusted computing_, among with all sad characteristics that "trusted computing" implies; you either have faith that it is working correctly, or your shoud not be making anything that you need security on a platform that embeds it.
  - ElectricalUnion 4y ago
    RHEL/Fedora going for unified /bin is about system recovery. On the types of systems you're expected to install RHEL, if you can't mount the root filesystem correctly, then /bin isn't going to help you either - what you need instead is that dracut put your repair/minimal tool set in your initramfs.
    - egberts1 4y ago
      System recovery should comprise of two distinct and separate components: - a simple, hardened and vetted “handler” - the upgradable components RedHat now chose to combine the two. And RedHat’s current approach is just now muddling security boundary between the two as my experience shows. This is not new trend but a constant battleground that I have personally fought alongside over many RedHat distros since 1998. After all, their customers are overwhelming them for ease of use of system recovery, as well as for security against persistence malware. But you cannot do both. That’s why Intel is taking another stab at TPM/ME. While Intel is reworking, the current and prudent thing to do is to lockdown the /bin (expand initramd mountings, and I think this should include a separate /usr mount so that / can be mount read-only for one mission profile and /usr be mount read-only for another) Of course, in these days and age, the best security is for /bin to be in a flash partition that is protected by a hardware switch, for /bin not to have any network tools/access, and for ME to be totally disabled (and if Intel ME cannot be disabled, then to never, ever use the management Ethernet port that ME is tied to).
      - ElectricalUnion 4y ago
        > But you cannot do both. That’s why Intel is taking another stab at TPM/ME. I trust Intel and their closed blob firmware much less that I trust Red Hat. > While Intel is reworking (...) > Of course, in these days and age (...) and for ME to be totally disabled (and if Intel ME cannot be disabled, then to never, ever use the management Ethernet port that ME is tied to). I agree that the current Intel ME isn't trustworthy. It is "trusted computing"/"treacherous computing" after all. But I am also very skeptical about a "new Intel ME" being trustworthy as well. > then to never, ever use the management Ethernet port that ME is tied to This doesn't help a lot when the ME has powers over protection ring -1, and can arbitrarily mess up with your main system.
  - soraminazuki 4y ago
    > NixOS, like totally tossed LFS out, 100% Not quite. NixOS still relies heavily on the FHS layout. It just dropped the usage of some global directories in order to provide features it otherwise couldn't have. More specifically: * Only a few top-level directories are actually dropped, like /bin, /lib, /share, and /usr. Well technically /usr exists, but it only has /usr/bin/env in it and /usr/bin is excluded from the default $PATH. * Individual packages placed under /nix/store/ still adheres to FHS. While packages technically don't need to adhere to FHS, Nix expects commands to be placed under ./bin, man pages under ./share/man, and so on and so forth.
    - egberts1 4y ago
      My bad, like 80%.
  - stryan 4y ago
    > RedHat/Fedora, they are smushing both /bin and /usr/bin together. This breaks any link with embedded world (and will come back to bite them when Intel ME becomes abandonware due to malware pervasiveness and their inability to keep those out. FYI, UsrMerge is being (rightfully) adopted by multiple distros including SUSE, Debian, and Arch.
    - egberts1 4y ago
      yes, that is the decision made by said distros in the best interest of working toward an easier but REMOTE recovery mechanism. Not something one would not want to do in terms of increasing the overhead of remote (and thusly its general) system administration nor weaken the security stance of an overall host. It may look good to do such smushing of [/usr]/bin for the short term but the introduction of vastly more surface attack areas should give any serious security architects the pause.
  - trasz 4y ago
    Solaris had merged /bin and /usr/bin for like two decades. The difference nowadays is mostly cosmetics; one is a symlink to the other and that’s mostly it. It could make a difference in the eighties when there was a reason for a separate /usr.
    - egberts1 4y ago
      yeah, that is true, I havent seen multi-source updater nor embedded feature within SolarisOS/SunOs.
      - trasz 4y ago
        Solaris was sometimes used embedded in some larger machinery, like AWACS.
Pringre 4y ago
[flagged]
- hypertele-Xii 4y ago
  This is a spam bot.
ElectricalUnion 4y ago
See the newer 3.0 (instead of this 2.3) in https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html
lotw_dot_site 4y ago
This kind of document really interests me. My project is called Linux on the Web, and has been under fairly active development for the past decade. I am trying to innovate on both operating system theory as well as application development best practices, all at the same time. The current top level directories in LOTW are: bin, etc, home, mnt, tmp, usr, var and www. There used to be a dev directory (and others) that really just added to the complexity of the codebase more than anything else. LOTW development is a constant balance between the age old "complexity vs functionality duality" in systems design theory.
- ElectricalUnion 4y ago
  How can you call a system "Linux" if you don't expose system operations in a file-like API? Granted, /dev is a pretty crappy way of doing it, but /proc, /sys and (bash shim, not actually a file) /dev/tcp are what I believe expected basic functionality of modern "Linux"
elric 4y ago
When I first started packaging software for $employer, we adhered to the FHS. Then we started shipping software to corporate customers, who have Policies and Rules and Expectations which are diametrically opposed to the FHS. They don't want logs in /var/log, nor binaries in /usr/[local]/bin, because then someone with root access has to be involved in the installation process. They don't even want an RPM if they can help it, for the same reason. In the end we revamped the whole shebang and everything lives in our own folder structure whose root can be anywhere, where everything can be owned by arbitrary users, because customers are afraid of root. They don't care that this makes their installation less secure, because they are convinced that it makes things more secure. shrug
- IshKebab 4y ago
  > because customers are afraid of root You mean because that's obviously way more sane than spewing the installation of every piece of software all over the system. There's a reason it's basically only Unix that works like that. Slightly disappointing that you were directly confronted with the problems of the FHS but still think it's better... because customers are idiots or something.
  - bhaak 4y ago
    With a proper package manager that keeps track of the installed files and a proper permission system, it doesn't matter where the files are.
    - Joker_vD 4y ago
      As long as you don't move them around without notifying the proper package manager: which one, by the way? There is dpkg, and apt, and npm, and pip3, and...
      - bhaak 4y ago
        If you install into the root hierarchy then you must use the one that your OS is using. Creating such a package for your application can be a nuisance but it really is not rocket science. You can only use language specific packager managers like npm and pip3 if you install into a specific sub directory outside of OS file hierarchy conventions.
nivethan 4y ago
Does anyone have any resources for other operating systems? This might be one of those things that I need to test drive OSes for but it'd be neat to just read about.
trasz 4y ago
See also hier(7), where most of this originated in sometime around 4.2BSD: https://www.freebsd.org/cgi/man.cgi?hier https://www.freebsd.org/cgi/man.cgi?hier
vbezhenar 4y ago
It’s a pity that every single docker container throws away those standards and uses some weird /prometheus directory. I’m still putting my apps into /opt or something like that.

46 points by nivethan 4y ago

jmclnx 4y ago

Too bad the major Linux Distros tossed this out the window years ago.

isabellat 4y ago
What in particular are you referring to? A lot of software still depends on paths that adhere to the FHS. Dynamic linkers, etc all bake in assumptions about search paths based on FHS. Certainly application developers will violate FHS when placing config files etc but I’m curious what the Distros are tossing out?
ElectricalUnion 4y ago
The only "major Linux Distro" that I know that actually doesn't follow FHS is NixOS, and even NixOS has FHS-compatible overlay options for handling proprietary/pre-compiled software.
egberts1 4y ago
Ummm, there is a general acceptance of a newer version of LFS, version 3. If version mistaken, you must be thinking of just two distros. - NixOS, like totally tossed LFSv3 out, 100% - RedHat/Fedora, they are smushing both /bin and /usr/bin together. This breaks any link with embedded world (and will come back to bite them when Intel ME becomes abandonware due to malware pervasiveness and their inability to keep those out.
- egberts1 4y ago
  A tiny smatters of Linux distro are smushing both /tmp and /var/tmp. That one is never a good idea, not even in production servers nor embedded world. /tmp gets emptied with each reboot. /var/tmp is about surviving across reboot. But the app would run just fine if it were ever to be emptied. # Alternatively Some have said that /var/cache would be the more appropriate use over /var/tmp. But /var/cache is used for daemon cold restart and reconstruction of internal structures after reboot, restart, reload, or worse, Ethernet cable disconnect under only systemd-networkd (daemon gets killed by systemd). Your prized networked daemon falls into this category. /var/tmp is generally for session-specific (that are expected to survive across reboot) as opposed to daemon’s internal structure. ISC DHCP client is one.
- packetlost 4y ago
  > This breaks any link with embedded world (and will come back to bite them when Intel ME becomes abandonware due to malware pervasiveness and their inability to keep those out. Can you expand on that? What does /usr/bin have to do with embedded systems programming??
  - egberts1 4y ago
    Glad you ask. In a really, really secured Unix environment, the /bin is typically a read-only partition. In a secured embedded world, this would be a separate flash hardware chip whose read-write is controlled by a hardware switch. Busybox would encompass most of the entries under /bin but it is often that package management must negotiate out-of-band with admin doing upgrades when using bigger “busybox” like GNU utils. Intel ME and its storage of binary blob has been problematic of defying clean delineation of nested security boundary, notably when TPM is not covering Intel ME to a point of Intel making another stab at TPM. So where do you put the upgrades for Intel Management Engine? This paper indirectly covers Intel’s future plan of dealing with these shortcomings. https://www.intel.com/content/dam/www/public/us/en/security-advisory/documents/intel-csme-security-white-paper.pdf https://www.intel.com/content/dam/www/public/us/en/security-... Today’s fight is about making these partitions as easy to upgrade as possible (for /bin.). My assertion is that remote upgrade^H^H^H^H^H^Hrecovery should never be a possibility when your /bin code has been thoroughly vetted and secured.
    - ElectricalUnion 4y ago
      > In a really, really secured Unix environment, the /bin is typically a read-only partition. > In a secured embedded world, this would be a separate flash hardware chip whose read-write is controlled by a hardware switch. I fail to see how this is secure without also securing /etc (PATH, LD_LIBRARY_PATH), /lib, /usr/lib, /usr/bin, /usr/local/bin - and at this point, might as well make the whole root mount thing RO and have a separated block device for the RW parts instead. > Intel ME and its storage of binary blob has been problematic of defying clean delineation of nested security boundary, notably when TPM is not covering Intel ME to a point of Intel making another stab at TPM. Intel ME is _trusted computing_, among with all sad characteristics that "trusted computing" implies; you either have faith that it is working correctly, or your shoud not be making anything that you need security on a platform that embeds it.
- ElectricalUnion 4y ago
  RHEL/Fedora going for unified /bin is about system recovery. On the types of systems you're expected to install RHEL, if you can't mount the root filesystem correctly, then /bin isn't going to help you either - what you need instead is that dracut put your repair/minimal tool set in your initramfs.
  - egberts1 4y ago
    System recovery should comprise of two distinct and separate components: - a simple, hardened and vetted “handler” - the upgradable components RedHat now chose to combine the two. And RedHat’s current approach is just now muddling security boundary between the two as my experience shows. This is not new trend but a constant battleground that I have personally fought alongside over many RedHat distros since 1998. After all, their customers are overwhelming them for ease of use of system recovery, as well as for security against persistence malware. But you cannot do both. That’s why Intel is taking another stab at TPM/ME. While Intel is reworking, the current and prudent thing to do is to lockdown the /bin (expand initramd mountings, and I think this should include a separate /usr mount so that / can be mount read-only for one mission profile and /usr be mount read-only for another) Of course, in these days and age, the best security is for /bin to be in a flash partition that is protected by a hardware switch, for /bin not to have any network tools/access, and for ME to be totally disabled (and if Intel ME cannot be disabled, then to never, ever use the management Ethernet port that ME is tied to).
    - ElectricalUnion 4y ago
      > But you cannot do both. That’s why Intel is taking another stab at TPM/ME. I trust Intel and their closed blob firmware much less that I trust Red Hat. > While Intel is reworking (...) > Of course, in these days and age (...) and for ME to be totally disabled (and if Intel ME cannot be disabled, then to never, ever use the management Ethernet port that ME is tied to). I agree that the current Intel ME isn't trustworthy. It is "trusted computing"/"treacherous computing" after all. But I am also very skeptical about a "new Intel ME" being trustworthy as well. > then to never, ever use the management Ethernet port that ME is tied to This doesn't help a lot when the ME has powers over protection ring -1, and can arbitrarily mess up with your main system.
- soraminazuki 4y ago
  > NixOS, like totally tossed LFS out, 100% Not quite. NixOS still relies heavily on the FHS layout. It just dropped the usage of some global directories in order to provide features it otherwise couldn't have. More specifically: * Only a few top-level directories are actually dropped, like /bin, /lib, /share, and /usr. Well technically /usr exists, but it only has /usr/bin/env in it and /usr/bin is excluded from the default $PATH. * Individual packages placed under /nix/store/ still adheres to FHS. While packages technically don't need to adhere to FHS, Nix expects commands to be placed under ./bin, man pages under ./share/man, and so on and so forth.
  - egberts1 4y ago
    My bad, like 80%.
- stryan 4y ago
  > RedHat/Fedora, they are smushing both /bin and /usr/bin together. This breaks any link with embedded world (and will come back to bite them when Intel ME becomes abandonware due to malware pervasiveness and their inability to keep those out. FYI, UsrMerge is being (rightfully) adopted by multiple distros including SUSE, Debian, and Arch.
  - egberts1 4y ago
    yes, that is the decision made by said distros in the best interest of working toward an easier but REMOTE recovery mechanism. Not something one would not want to do in terms of increasing the overhead of remote (and thusly its general) system administration nor weaken the security stance of an overall host. It may look good to do such smushing of [/usr]/bin for the short term but the introduction of vastly more surface attack areas should give any serious security architects the pause.
- trasz 4y ago
  Solaris had merged /bin and /usr/bin for like two decades. The difference nowadays is mostly cosmetics; one is a symlink to the other and that’s mostly it. It could make a difference in the eighties when there was a reason for a separate /usr.
  - egberts1 4y ago
    yeah, that is true, I havent seen multi-source updater nor embedded feature within SolarisOS/SunOs.
    - trasz 4y ago
      Solaris was sometimes used embedded in some larger machinery, like AWACS.

Pringre 4y ago

[flagged]

hypertele-Xii 4y ago
This is a spam bot.

ElectricalUnion 4y ago

See the newer 3.0 (instead of this 2.3) in https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html

lotw_dot_site 4y ago

This kind of document really interests me. My project is called Linux on the Web, and has been under fairly active development for the past decade. I am trying to innovate on both operating system theory as well as application development best practices, all at the same time. The current top level directories in LOTW are: bin, etc, home, mnt, tmp, usr, var and www. There used to be a dev directory (and others) that really just added to the complexity of the codebase more than anything else. LOTW development is a constant balance between the age old "complexity vs functionality duality" in systems design theory.

ElectricalUnion 4y ago
How can you call a system "Linux" if you don't expose system operations in a file-like API? Granted, /dev is a pretty crappy way of doing it, but /proc, /sys and (bash shim, not actually a file) /dev/tcp are what I believe expected basic functionality of modern "Linux"

elric 4y ago

When I first started packaging software for $employer, we adhered to the FHS. Then we started shipping software to corporate customers, who have Policies and Rules and Expectations which are diametrically opposed to the FHS. They don't want logs in /var/log, nor binaries in /usr/[local]/bin, because then someone with root access has to be involved in the installation process. They don't even want an RPM if they can help it, for the same reason. In the end we revamped the whole shebang and everything lives in our own folder structure whose root can be anywhere, where everything can be owned by arbitrary users, because customers are afraid of root. They don't care that this makes their installation less secure, because they are convinced that it makes things more secure. shrug

IshKebab 4y ago
> because customers are afraid of root You mean because that's obviously way more sane than spewing the installation of every piece of software all over the system. There's a reason it's basically only Unix that works like that. Slightly disappointing that you were directly confronted with the problems of the FHS but still think it's better... because customers are idiots or something.
- bhaak 4y ago
  With a proper package manager that keeps track of the installed files and a proper permission system, it doesn't matter where the files are.
  - Joker_vD 4y ago
    As long as you don't move them around without notifying the proper package manager: which one, by the way? There is dpkg, and apt, and npm, and pip3, and...
    - bhaak 4y ago
      If you install into the root hierarchy then you must use the one that your OS is using. Creating such a package for your application can be a nuisance but it really is not rocket science. You can only use language specific packager managers like npm and pip3 if you install into a specific sub directory outside of OS file hierarchy conventions.

nivethan 4y ago

Does anyone have any resources for other operating systems? This might be one of those things that I need to test drive OSes for but it'd be neat to just read about.

trasz 4y ago

See also hier(7), where most of this originated in sometime around 4.2BSD: https://www.freebsd.org/cgi/man.cgi?hier https://www.freebsd.org/cgi/man.cgi?hier

vbezhenar 4y ago

It’s a pity that every single docker container throws away those standards and uses some weird /prometheus directory. I’m still putting my apps into /opt or something like that.