Date: Tue, 6 Apr 2004 21:46:45 -0400 From: Alan Cox <alan@xxxxxxxxxx>
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.
_________________________________________________________________
Tax headache? MSN Money provides relief with tax tips, tools, IRS forms and more! http://moneycentral.msn.com/tax/workshop/welcome.asp
