Re: [gentoo-dev] Opinion against /usr merge

["llemikebyw@aol.com" <llemikebyw@aol.com>]

In the beginning there were root (/bin) and /usr programs

See UNIX Programmer's Manual (Thompson, Ritchie, November
1971). [http://cm.bell-labs.com/cm/cs/who/dmr/manintro.pdf]

/usr programs were "not considered part of the UNIX system"
[bottom of page ii].

Root (/) contained all the system files and configuration;
/usr all the user's files.

In the UNIX V7 manuals hosted here:
http://plan9.bell-labs.com/7thEdMan/bswv7.html
Dennis Rtichie suggests moving binary files from root (/bin)
to /usr/bin because it might speed up systems:
See page 152 of UNIX Version 7, Volume 2B
UNIX Programmers Manual.

Hence, he suggests leaving only maintenance binary files in
root (see para. 3 under Disk Layout, Pg. 152).

The most important remark comes in paragraph 2 of the disk
layout page:

"There are two considerations in deciding how to adjust the
arrangement of things on your disks: the most important is
making sure there is adequate space for what is required;
secondarily, throughput should be maximised."



For me the argument is about what gets mounted in which way.
I want to be able to ensure filesystems are mounted to prevent
potential privilege escalation.
Consequently, I have split my Gentoo system with the following
settings.

At boot /usr is present in / (on same partition)
/tmp is mounted nosuid from a separate partition
/var is mounted nosuid from a separate partition
/home is mounted nosuid from a separate partition

/bin and /sbin programs that do not require root authority
are all marked nosuid.

None of the executables/configuration files in / or /usr are
user-writable.

umasks are 077.

On my backup server, /home is mounted noexec, nosuid.

Personally I like the split between /bin and /usr/bin and /sbin
and /usr/sbin - provided ports maintainers stick to an
understanding that /bin is for maintenance files and /usr/bin
is for user application files (i.e. applications used by users).

/sbin and /usr/sbin should segregate root's/system maintenance
executables and root's/system application executables.


Although I am not sure at all that executables have been so
split by recent developers/maintainers (a lot of time has passed)...

It would be nice if a sensible structure could be proposed and
agreed by ALL Linux distributions (coordinated with BSD).

For me, it is a credit to Ken and Dennis' vision that they foresaw
the benefit of file permissions, including suid and sgid and the
EXCEPTIONALLY BRILLIANT idea of the sticky bit for /tmp.

It is incredible that they came up with much of this structure in
1969 - 1978.

"Progress, far from consisting in change, depends on retentiveness.
When change is absolute there remains no being to improve and
no direction is set for possible improvement: and when experience
is not retained, as among savages, infancy is perpetual.
Those who cannot remember the past are condemned to repeat it."
SATAYANA

Those querying a separate /usr partition or otherwise might like to
peruse UNIX Version 7 UNIX Programmers manual, Volume 2A:
UNIX for Beginners (Brian W. Kernighan)
Page 46 of this PDF: http://plan9.bell-labs.com/7thEdMan/v7vol2a.pdf

I LIKE THE IDEA of a separate /usr partition - but that is from a
mounting file-systems perspective rather than relying on the history
of UNIX...

Live free or die - UNIX.

Mike




On 18/07/12 18:35, Canek Peláez Valdés wrote:
> As William pointed out, this is just another silly rationalization
> done after the fact. But, just for argument's sake, lets suppose that
> "usr" was named like that because it was the acronym for "UNIX System
> Resources".
>
> *Who cares about that now?* It was 43 years ago. My cellphone is
> thousands of times faster than the PDP-7 Unix was originally developed
> for, and it has millions of times more storage. The length
> restrictions imposed on system directories are completely superfluous
> now.
>
> All the arguments for keeping /bin, /sbin, /usr/bin, and /usr/sbin
> separated are really instances of the Chewbacca defense [1]. They just
> don't make any sense.