Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

lists.busybox.net

Post reply on HN
Print view View original

91–100 of 131 posts

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#91

Post by nickpsecurity »

ploxiln wrote: post #6
IshKebab wrote: post #2

I wonder what is more likely in our lifetimes - a sane Linux filesystem layout, or viable fusion power. Honestly I'm not sure.

gobolinux - http://gobolinux.org/ - has had a completely different filesystem layout, for many years. It's languished in the past few. archlinux has for a couple of years symlinked /bin, /sbin, and /usr/sbin to /usr/bin, and /lib, /lib64 to /usr/lib https://wiki.archlinux.org/index.php/arch_filesystem_hierarc... If you make your own linux distro from scratch, you can get many of the open source pieces of a linux dist…

re gobolinux

That's the one I was trying to think of! Yeah, they solved the directory problem. NixOS solved the packaging problem. Little projects doing what they can to fix the UNIX/Linux mess.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#92

Post by marcosdumay »

ChuckMcM wrote: post #44

Interesting. First there was /bin for the things that UNIX provided and /usr/bin for the things that users provided. Part of the system, it lived in /bin, optional? it lives in /usr/bin. In SunOS 4 (and BSD 4.2 as I recall) the introduction of shared libraries meant you needed a "core" set of binaries for bootstrap and recovery which were not dynamically linked, and so "static" bin or /sbin (and its user equivalent /…

> since your computer and you are the only "user" (usually) so why not put everything in the same place

The Linux (and late UNIX) way was not changing the /usr for each user, but on sharing /usr through several computers. This way, you had to administer just one computer, for a network of any number of terminals.

That become obsolete only after modern package and configuration managers were created.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#93

Post by gkya »

orik wrote: post #4
nickpsecurity wrote: post #3

NixOS is one of the few distros that recognizes and solves this problem: https://nixos.org/nixos/about.html A solution like theirs should become the default. Their transactional, package management too given the number of times my Linux packages got broken by some ridiculous crap. That even a smaller outfit could knock out two problems, one major, shows these bigger distros could be gradually knocking out such issues…

I was about to ask if any BSD's handle this better, great to see that NixOS does.

In FreeBSD the base system stuff goes into /bin /lib and /etc, and all the ports target /usr/local as the prefix. Even the config files of the ports go to /usr/local/etc.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#94

Post by dingaling »

majewsky wrote: post #83
Annatar wrote: post #48

The elephant in the room is /opt, /etc/opt, and /var/opt. The System V and filesystem hierarchy specifications say that those locations are, and I quote, "for third party and unbundled applications". Yet some distributions, like for instance Debian or Ubuntu, do not even include them, precluding commercial software vendors from ever delivering software for those operating systems (no, an unbundled application can nev…

> Yet some distributions, like for instance Debian or Ubuntu, do not even include them, precluding commercial software vendors from ever delivering software for those operating systems What? Why should it be impossible for a third-party package to just create /opt? They will probably need to extend the PATH and LD_LIBRARY_PATH, but /etc/profile.d is very much standardized AFAIK.

Indeed Adobe Reader for Linux used to land itself in /opt on Ubuntu.

The power of run-as-su installers...

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#95

Post by jwilk »

Annatar wrote: post #48

The elephant in the room is /opt, /etc/opt, and /var/opt. The System V and filesystem hierarchy specifications say that those locations are, and I quote, "for third party and unbundled applications". Yet some distributions, like for instance Debian or Ubuntu, do not even include them, precluding commercial software vendors from ever delivering software for those operating systems (no, an unbundled application can nev…

Debian does include /opt and friends, as required by FHS: https://sources.debian.net/src/base-files/9.6/debian/postins...

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#96

Post by dredmorbius »

majewsky wrote: post #82
dredmorbius wrote: post #39

Reasons why you still might want to keep / and /usr isolated: 1. NFS mounts. Your local or initial BOOTP image has a minimal root, your (non-root-writeable, BTW) NFS /usr has Other Stuff. 2. Mount options. Root is often (and perhaps still must be -- /etc/mtab for example -- I've stopped closely tracking discussion to make root fully read-only) writeable. It may also require other mount permissions, including device f…

mtab is not a problem anymore. On Arch, /etc/mtab is just a symlink to /proc/self/mounts. As for the recovery partition, you don't need the split for that, either. Just have a live system on the recovery partition that mounts the normal root FS. Then you can chroot into there for recovery tasks.

Right, that seemed to be the mtab solution Debian were angling toward. I think there were some odd edge cases where it didn't behave well, though I don't recall what those were. Perhaps the ability to specifically edit the contents to allow fixing of fubared mounts -- almost certainly loopback or NFS, both of which get quite twitchy at times.

I don't recall my precise thinking on a clean root vs. /usr split on the recovery partition, though it may have avoided some confusion over binaries. Or perhaps that you could mount the /usr partition itself independently if you wanted, assuming primary root was hosed.

Not being able to mount a separate /usr would negate that option.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#97

Post by eridius »

jordigh wrote: post #75
eridius wrote: post #57

Earlier quoted context omitted.

What you've just described is a completely insecure hardware platform. Giving out a second private key that can still be used to install third-party updates is just as insecure as giving out their normal private key, the only real difference is if anyone actually looks at the code signature they can tell the difference between third-party and first-party code. Allowing the user to lock out that second key doesn't fix…

Actually, I think Apple is already more or less compliant with this part of GPLv3, as they allow developers to self-sign the software, right? You just have to pay for a self-signing key. That's sufficient, because it means you can run modified software. All they have to do is lift the restriction to pay for the self-signing key.

I'm talking about the OS here. But the App Store is also incompatible with GPLv3 and GPLv2 for other reasons.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#98

Post by eridius »

malka wrote: post #63
eridius wrote: post #57

Earlier quoted context omitted.

What you've just described is a completely insecure hardware platform. Giving out a second private key that can still be used to install third-party updates is just as insecure as giving out their normal private key, the only real difference is if anyone actually looks at the code signature they can tell the difference between third-party and first-party code. Allowing the user to lock out that second key doesn't fix…

Each user would get its own private key that could only be used on its own device. It could not be used to sign software for someone else device

Hmm, that's actually the first suggestion I've heard that's at least technically workable, though it's pretty darn impractical to do at any kind of scale.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#99

Post by eridius »

tremon wrote: post #88
eridius wrote: post #30

Earlier quoted context omitted.

Or to put it another way, GPLv3 mandates that your hardware be insecure (because you cannot prevent a malicious actor from installing malicious software on someone's device, which would normally be done by requiring all updates to be codesigned by the manufacturer). And it's not just limited to software that would be installed on the hardware; companies like Apple won't even allow employees to install GPLv3 software…

GPLv3 mandates that your hardware be insecure Oh please. It really doesn't, it merely mandates that the user is able to override a manufacturer's lockdown. Not that any nitwit should be able to override a user's lockdown.

A platform that is insecure-by-default and relies on users being knowledgeable and motivated enough to learn how to lock down their own devices is still an insecure platform.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#100

Post by eridius »

jordigh wrote: post #78
eridius wrote: post #30

Earlier quoted context omitted.

Or to put it another way, GPLv3 mandates that your hardware be insecure (because you cannot prevent a malicious actor from installing malicious software on someone's device, which would normally be done by requiring all updates to be codesigned by the manufacturer). And it's not just limited to software that would be installed on the hardware; companies like Apple won't even allow employees to install GPLv3 software…

> Also don't forget the patent stuff in GPLv3. That's not quite as scary as the anti-TiVoization stuff, but it's still pretty significant for large companies. The Apache license has a nearly identical clause (in fact, I believe GPLv3 was inspired from the Apache license) and companies like Google and Apple have used the Apache license without destroying their business. Anti-retaliation clauses don't seem to be a deat…

GPLv3's patent clause is effectively identical to Apache License, Version 2.0? I wasn't aware of that. I haven't done much research on the patent angle, I only brought it up because I actually talked to one of Apple's lawyers at one point about GPLv3 and they brought up the patent stuff as an issue.
Post reply on HN