[RFC] User Accesable Filesystem Hierarchy Standard

Thu Apr 1 05:10:05 UTC 2004

>From: Robert Marcano <robert at marcanoonline.com>
>Date: Wed, 31 Mar 2004 16:51:55 -0400
>
>On Wed, 2004-03-31 at 15:47, Gary L Greene Jr wrote:
>
> > On Saturday 27 March 2004 06:05 pm, Robert Marcano wrote:
>...
> > >
> > > I am sure that the filesystem can be arranged in order to make it more
> > > easy to use to the desktop user, Your ideas of a shared directory is
> > > nice, but letting the user "Easily install software without escalating
> > > their privileges" is something that I don't like. The only way that I
> > > like a shared directory is if it is mounted from a filesystem with the
> > > "noexec" flag.
> > >
> > > I think that the software installation can be made easy with the help 
>of
> > > a better "Add/Remove Programs", and the security aspect could be
> > > enhanced with the help of a SELinux policy for this program(s) (I am 
>not
> > > an expert in SELinux, so I could be wrong)
> >
> > The problem with adding software installation only through the root
> > directories is that you still need to have root privileges to install a
> > program. This proposal is to allow people to install programs, but not 
>as
> > root. This adds no new abilities. None. It just makes it easier. 
>Already,
> > people can install any program in their home directory, it is just a lot 
>of
> > hassle. This is just a way to organize it.
>
>For what I have learned of SELinux, I think that it could be used to
>give special privileges to certain processes (for example the Add/Remove
>programs of the distribution) to do whatever it wants on the system by
>defining the appropriate SELinux policy. For example the policy can
>allow to a program to install new files on /usr/{bin,lib,share,...} or
>update the files of a previously installed version of the application
>without asking any root credentials to some users of the system, or all
>if wanted. This is the more secure way I think it can be done

SELinux is a tool with the ability to provide a secure way to access other 
directories. However, this is not a Linux standard in particular. If it is 
intended to be a standard, it needs to support any system which uses a 
hierarchal filesystem in the usual Unix manner. However much I like 
SELinux's abilities, that seems to be an extension which needs to be added 
by a distribution.

>... continues ...
>
> > The purpose is for home installation. Here is a sample setup: I have a
> > computer used by four people. I own it and want to run it. I want to 
>allow
> > the other people to install programs without asking me. This lets them 
>do
> > installations without needing to be root.
> >
> > This doesn't pose a security issue because the programs installed thus 
>do not
> > have higher privileges than those of the user that installed them.
> >
> > This will in fact improve security on many home installations because 
>users
> > will not need to be constantly entering their root password and will be 
>less
> > likely to just turn the root password off.
>
>Leaving to another time my differences with your proposal ;-), I think
>that you must add to your document information about the search order of
>the PATH, LD_LIBRARY_PATH, etc. You can include for example that for
>security reasons it is mandatory that the system libraries and
>executables need to be loaded before any user installed ones; or the
>other way: in order to allow the upgrade of system installed
>applications the search path is reversed to allow that. What the
>standard will recommend? changes to LD implementation in order to allow
>the load of the user installed shared libraries. or the usage of the
>environment variable LD_LIBRARY_PATH

Interestingly enough, the order of items in the PATH and LD_LIBRARY_PATH are 
not part of the previous FHS standard and I see no reason to standardize 
them in an extension. This merely deals with the directory layout. That is a 
separate level which might need a separate standard of its own.

>Do you know that a lot of user oriented applications store files on
>/usr/share (and others)?, and that directory is defined at compile time
>(nearly on every application that uses it), so you will need to build
>the application specially for the directory you are deploying, and on
>"home installations" the users will not build their custom versions

I was under the impression, from personal experience, that almost all of 
them define a $PREFIX and can use any share which is appropriate to that 
prefix. Moving the directories into a format more like '~/.system/bin/' 
would give a full set of standard directories to install to, just as is 
currently available to allow installation into several areas.

Although some binary distributions may not support this, that is 
unavoidable. It is supportable, and they should support it, and there is 
little that can be done if they do not. (If there is a work around, please 
inform me.)

>
> > Also, note that this is not intended for server installs, as is stated 
>in the
> > proposal.
> >
> > Thank you for the feedback.
>
>Hope this helps
>
>--
>Robert Marcano

_________________________________________________________________
Get rid of annoying pop-up ads with the new MSN Toolbar – FREE! 
http://toolbar.msn.com/go/onm00200414ave/direct/01/