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

71–80 of 131 posts

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

#71

Post by dTal »

eridius wrote: post #30
jordigh wrote: post #27

Earlier quoted context omitted.

I wonder if people even know what those restrictions are and how exactly the anti-tivoisation clause works. It does not forbid anyone from running software on tivoised devices, which is what some people seem to think it does. All that it requires is that if you distribute the software primarily to be used on a User Product (as GPLv3 calls it), then as part of the installation information (which in GPLv2 used to just…

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…

Is there a problem with, say, printing the key on the device case, as is done with administrator passwords for consumer routers? Or, if you're worried about casual skimming, inside the case? Under a tamper seal if it makes you feel better? You're basically at the Chromebook security model by that point, which seems well-regarded around here.

It's pointless anyway trying to "secure" hardware against a sufficiently determined attacker with physical access. There's an argument to be made that physical access should equal software ownership, philosophically.

It's also worth noting that requiring all updates to be signed by the manufacturer does not protect you from malicious code, as manufacturer updates can also be malicious. Ultimately, the "owner" of the device should be at the top of the pyramid of trust.

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

#72

Post by mattmanser »

teamhappy wrote: post #70

/{bin,sbin} is for stuff you cannot live without (e.g., sh, mkdir, chmod, rm, ln, etc.) /usr/{bin,sbin} is for stuff you can live without but expect to be there (e.g., make, grep, less). /usr/local/{bin,sbin} is for stuff you/your local admin installed (e.g., mosh, cmake). Also, I use $HOME/{bin,sbin} for wrapper scripts, binaries that I need but don't want to install system-wide (single-file C utils that come withou…

Did you read the link?

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

#73

Post by teamhappy »

mattmanser wrote: post #72
teamhappy wrote: post #70

/{bin,sbin} is for stuff you cannot live without (e.g., sh, mkdir, chmod, rm, ln, etc.) /usr/{bin,sbin} is for stuff you can live without but expect to be there (e.g., make, grep, less). /usr/local/{bin,sbin} is for stuff you/your local admin installed (e.g., mosh, cmake). Also, I use $HOME/{bin,sbin} for wrapper scripts, binaries that I need but don't want to install system-wide (single-file C utils that come withou…

Did you read the link?

Yup. I'm not sure what you're hinting at though. Are you saying that's not really why they exist? True, but that's how people use them.

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

#74

Post by nilved »

teamhappy wrote: post #70

/{bin,sbin} is for stuff you cannot live without (e.g., sh, mkdir, chmod, rm, ln, etc.) /usr/{bin,sbin} is for stuff you can live without but expect to be there (e.g., make, grep, less). /usr/local/{bin,sbin} is for stuff you/your local admin installed (e.g., mosh, cmake). Also, I use $HOME/{bin,sbin} for wrapper scripts, binaries that I need but don't want to install system-wide (single-file C utils that come withou…

Regarding your last sentence, why does having grep in /bin reduce the chance of mkdir working?

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

#75

Post by jordigh »

eridius wrote: post #57
gherkin0 wrote: post #38

Earlier quoted context omitted.

> 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). I think that's wrong: http://www.gnu.org/licenses/gpl-faq.en.html#GiveUpKeys : > I use public key cryptography to sign my code to assure its authenticity. Is it true that GPLv3…

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.

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

#76

Post by teamhappy »

nilved wrote: post #74
teamhappy wrote: post #70

/{bin,sbin} is for stuff you cannot live without (e.g., sh, mkdir, chmod, rm, ln, etc.) /usr/{bin,sbin} is for stuff you can live without but expect to be there (e.g., make, grep, less). /usr/local/{bin,sbin} is for stuff you/your local admin installed (e.g., mosh, cmake). Also, I use $HOME/{bin,sbin} for wrapper scripts, binaries that I need but don't want to install system-wide (single-file C utils that come withou…

Regarding your last sentence, why does having grep in /bin reduce the chance of mkdir working?

I doesn't reduce the chance of mkdir working but it does increase the chance of you missing a bug in the part of your source tree that needs to be rock solid.

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

#77

Post by bretthoerner »

adwf wrote: post #23
m45t3r wrote: post #15

For all people that think this is still a issue: it is not: * Arch Linux: https://wiki.archlinux.org/index.php/Arch_filesystem_hierarc... * Fedora: https://fedoraproject.org/wiki/Features/UsrMove * Debian: https://wiki.debian.org/UsrMerge * Ubuntu: https://wiki.ubuntu.com/FoundationsTeam/Specs/Quantal/UsrMer... And this is true for quite a long time. I think the last distro that did /usr merge is Debian and this is a…

Arch still occasionally has some packages installed to /opt. Annoying as hell, but they expect to be there for some reason. Android-studio was the latest unexpected surprise for me.

fwiw that's from AUR, not Arch official.

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

#78

Post by jordigh »

eridius wrote: post #30
jordigh wrote: post #27

Earlier quoted context omitted.

I wonder if people even know what those restrictions are and how exactly the anti-tivoisation clause works. It does not forbid anyone from running software on tivoised devices, which is what some people seem to think it does. All that it requires is that if you distribute the software primarily to be used on a User Product (as GPLv3 calls it), then as part of the installation information (which in GPLv2 used to just…

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 death knell.

http://en.swpat.org/wiki/Patent_clauses_in_software_licences...

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

#79

Post by kakwa_ »

digi_owl wrote: post #56
bbanyc wrote: post #12

Nitpicking: If you look at the very early versions of the Unix manuals, before even /lib was invented, there was a notion that /bin was the "system" (section 1) and /usr/bin was "user software" (section 6). This fell by the wayside when they ran out of disk space on / and started putting section 1 commands in /usr/bin. At some point the system/user distinction was abandoned and everything but the games got moved to s…

I can't help think that initramfs is a pox on Linux. It seems to lead to all kinds of "solutions" that are bothersome at best to maintain unless you have big dollars at your back.

I've never quite understood it myself.

It's far from mandatory (I've run Gentoo for years without it) and when you have to fix stuff in the mkinitrd script, you just cry...

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

#80

Post by arca_vorago »

spc476 wrote: post #51
JdeBP wrote: post #47

Earlier quoted context omitted.

You are quoting 2013 doco. systemd has (again) changed since then. As of 2016, the position is that whilst there is still code in some of the program to handle a split /usr, a significant part of the system (in particular Plug and Play device management) now references /usr and depends from it, to the extent that it is already a requirement that /usr be always present: i.e. that it either be on the root volume or be…

So, as Linus controls the kernel, Lennart wants to control userspace?

I have a sneaking suspicion one day systemd is going to try to replace the gnu in gnu/linux.
Post reply on HN