Re: [RFC] User Accesable Filesystem Hierarchy Standard

>From: Zackary Deems <zdeems-tClYnr7/[email protected]>
>Date: Mon, 29 Mar 2004 10:27:02 -0500
>
>Speaking of which.. what exactly is your target audience?  I don't see that 
>allowing 'private' installs gains you much, and adds an unnecessary layer 
>of complication to the install/build process.  I think it might be 
>completely necessary for a very small minority of users, but would be a 
>pretty big waste of time for most home desktop users.. and would make 
>administration of the machines a nightmare.  The main audience I can 
>imagine getting much out of that would be kids who want to hide their 
>'special' programs from their parents.. which isn't much of an audience for 
>a cross-distribution specification.  Maybe I'm wrong, but the home desktop 
>environments I'm familiar with typically have one to two computers which 
>may or may not be networked, and have MAYBE four users total. The people 
>who have replied to the RFC to date are not what I would call 'typical' 
>desktop users.. they're people who use their linux server as a desktop.. 
>which is not the same.

The target audience is primarily that 1-4 user home desktop system, although 
it might possibly include other targets. See below for explanations of where 
private installs would be used.

>I totally agree.  Using a new 'user' root actually WOULD create a new layer 
>of overall system security, as long as somebody makes sure that no program 
>is installed SUID root.

Yep, buts that's something we can't really stop. Oh well, if only people 
practiced good security on their own.

> > Not everything should be installed to that new section. The purpose is 
>partly that newly installed
> > programs won't need to be installed into the main system. This should, 
>to some extent, prevent
> > malware and trojans from messing with system files because they can be 
>installed without ever
> > gaining access to system files. Also, it means people really don't need 
>to mess with the root
> > system as often. However, many things still should be made root 
>installs.
>
>Hmm.. I tend to disagree.  I think that your specification with regards to 
>vanilla user software installs is perfect right up to the point where you 
>talk about private installs and special situations.  From an administrative 
>standpoint, I think you alleviate part of your problem by doing every 
>install in such a way that only the user who installs each program (or 
>root) can uninstall or reconfigure it.

I'm somewhat torn on this issue, and wish I could get responses from more 
people about this. First off, the standard only is to define the 
directories, not their permissions, so that won't be required, it will only 
be recommended (likewise, the FHS doesn't require that /bin be owned by 
root, but it is usually done that way). The Concerns section actually 
mentions most of my comments on this.

However, with more thought on it, having only a shared dir, not private 
dirs, does sound somewhat more tempting. I should note that the long-term 
idea was that users would be prompted with three effective installation 
options of private, shared, and system, which is what would make this 
powerful. This standard just gives the framework for such a tool to work 
inside of. I see no issues with the shared and system sections, but perhaps 
some with the private ones.

A Private install gives the advantages of:

- I can install something that other users don't want, and it can be 
automatically setup to not be all over their menus and file-associations
- I can install something which I want other users to not be able to access
- I can install a conflicting version of a program for myself (binaries 
aren't usually versioned, so this is sometimes a problem)
- I can install a program into my personal limited space in a more massive 
environment (I have a lab account with 250 megs space. I can install into 
that, but it is a lot of hassle. Such an environment might not want a shared 
area, but might want to allow a private area.)

I do not know how many people would use this. What I do know is that I would 
use this if I were still in a multi-user environment.

For a concrete example of when I would be using this: I do KDE development. 
I just go right ahead and use bleeding-edge everything, and I accept that 
things break on occasion. If I were still at home, my mother would be 
abominably angry if I did this, so I would need to have a private 
installation.

>Limiting it that way leaves the goal clear, uncomplicates the changes which 
>will be necessary to implement this new specification, keeps administration 
>somewhat simple, does not impact systems which may be importing this home 
>directory (via nfs or some other networked method), and allows the whole 
>thing to be easily uninstallable.  I think this specification should be 
>implemented as a package which can be installed and removed, meaning that 
>removal of the package and all previously user-installed packages, must be 
>simple and straightforward.

I'm not entirely sure what you mean by the whole thing being uninstallable 
and being implemented as a package. This is targetted as something which 
would be setup by a distribution. And, even besides that, it's merely a set 
of directories. If the directories are deleted, it's gone.

P.S. Sent this wrong the first time, sorry.

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