[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [RFC] User Accesable Filesystem Hierarchy Standard

From: Robert Marcano <robert 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/

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]