On Tue, Apr 06, 2004 at 09:36:24PM -0400, Jamethiel Knorth wrote:
> Actually, the idea does allow people to install shared programs. Part of
> the purpose of this is that a user can install a shared program without
> escalating their privileges. Of course, a system can be set up to
prevent
> this. The main advantage in a home environment is that, if a user does
> install something, it needn't be installed with root permissions.

Your typical home user will install prebuilt packages using the tools
provided with the system. In a non home environment you rarely want users
installing anything, and with SELinux you can go so far as to make
just about anything user originated (scripts included tho its a bit
tricky) non-executable. This is good as it turns "I got this cool christmas
card and ran it" into "I asked the sysadmin why it wouldnt run and she told
me
about trojans".

This is meant to be useable by any system, not only a Linux system, and not
only an SELinux system either.

Many environments do not have sysadmins. Those with sysadmins could have
different permission sets. This does nothing to prevent this. In those
environments (home desktop) without sysadmins, the result would often be "I
got this cool christmas card and it wouldn't run so I just typed in my root
password and then it worked fine. Hey, why is my computer F'ed up?"

And, this system would be used by the package manager as well. There is
nothing preventing a package manager from supporting this, although the
support will likely not be immediate.

Also, after a little more thought, the 'shared' directory will be changed in
the next revision of the draft, so that it isn't a specific requirement.
That is merely going to be a group directory which is optional and has a
standard name (somewhat like '/home/' is optional in the FHS).

> Looking at the current situation with Windows, it's fairly reasonable to
> assume that regular users will intentionally install programs without
> properly checking what they are and who made them. If they do this with
> root privileges, the program could influence every portion of their
system
> and this could cause catastrophic problems.

"Other people fire shotguns at random without warning, lets all do that"

More like, "People have a tendency to fire shotguns at random without
warning. Mayhaps we should expect them to."

Maybe there is an argument for a /usr/local/ with default labels that
prohibit privileged roles using the contents and which doesn't require
total superuser rights to write into.

That also solves
- The 10,000 private installations of epic problem

The 10,000 private installations can be solved by a decent package
management system which will notify the administrator of multiple
installations. This system will also make it more likely an administrator is
aware of a private install if a user's home directory is allowed to have
execute permissions. Obviously, if they are not allowed that, the
administrator decided not to follow this standard. The standard is intended
to organize user access to the filesystem, which is not desired in all
situations.

- The cross platform problem

This is fairly well solved by the different <distro>/<arch>/ structures.
Also, when config/ is moved into those <distro>/<arch>/ directories, this
will aid in allowing a user to have configuration files for multiple
environments, which would apparently be an improvement over the current
system.

- Non-exec /home

Additionally, this standard adds a way to have programs and documents easily
shared throughout groups with the addition of group directories, which is
currently rather lacking. The last time I ran into a group project, the
sharing of stuff was so much trouble, people decided to just share out
massive swaths of their home directories and hope no-one else messed with
them.