Check the comment by jmorris42 earlier in the thread, he's already explained why it would be nice to have /usr with all the executable files in it mounted read-only at all times, except when you're upgrading the system. The security benefit alone is tremendous.
Posted Jan 27, 2012 12:15 UTC (Fri) by njwhite (subscriber, #51848)
[Link]
The security benefit of mounting read-only is marginal. If a user has access to write files which are marked read-only in the filesystem, they have access to remount /usr read-write. Unless I'm missing something?
The case for the /usr merge
Posted Jan 27, 2012 16:52 UTC (Fri) by raven667 (subscriber, #5198)
[Link]
Read-write access can be controlled at the server for networked filesystems and not overridden by the client. Even in a local filesystem case it can prevent accidental modification or break canned exploit scripts
The case for the /usr merge
Posted Jan 27, 2012 18:31 UTC (Fri) by iabervon (subscriber, #722)
[Link]
Just having /usr mounted read-only isn't that big a win, but if the system will work with /usr mounted read-only, it will also work (which real benefits) if /usr is storage the system is technically incapable of modifying. (That is, where changing it requires doing something entirely different, like swapping CDs or flipping a physical switch on the device or something like that; or where it is a different system which can modify it.)
The case for the /usr merge
Posted Jan 27, 2012 18:08 UTC (Fri) by jmorris42 (subscriber, #2203)
[Link]
And I just had another thought along those lines.
With this change /usr is basically the same as \Windows, the whole OS is in one directory except we are smart enough to pull out the dynamic info into /var and /etc. Now we just make /etc a symlink to /var/etc and we get the whole operating system down to two directories, one per host changing information and one static read only binaries, libraries and documentation.
Of course they are also busy repolluting / with new top levels, otherwise we could look forward to a root with only:
/boot for the boot loader, kernel and initrd
/dev
/home for users
/media as the modern replacement for /mnt
/opt, probably can't get 3rd party vendors to give up on that one.
/proc for the kernel
/root since it probably can't go in /home/root safely
/sys for the kernel
/usr for the OS
/var for the OS
Plus symlinks for /bin, lib and /sbin. But I currently have /cgroup, /run and /srv cluttering things up. Why did we need those others in root and not somewhere under /var or /sys?
The case for the /usr merge
Posted Jan 27, 2012 20:08 UTC (Fri) by sytoka (subscriber, #38525)
[Link]
/lib64 is just horrible. Debian have a nice solution for multi-arch that will be maybe in wheezly....
The case for the /usr merge
Posted Jan 28, 2012 12:27 UTC (Sat) by Wol (guest, #4433)
[Link]
Are they changing release names from Toy Story to Harry Potter? :-)