Re: [RFC] User Accesable Filesystem Hierarchy Standard

What I mean by this being installable.. is that I want your 
specification's implementation to be an in the form of an RPM I can 
install or remove.  Something I can offer to users, but not force on 
them.. so that they don't have to decide which ISO to download, or so 
they don't have to go back and reinstall if they choose poorly at 
install time.  etc.

see comments below:

Jamethiel Knorth wrote:

>
> 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 don't think you're going to see this sort of install used anywhere BUT 
in a home environment, so you're actually imposing more potential 
problems with private installs, than you are providing solutions.

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

That's one of the gotchas that's going to have to be worked out.. 
otherwise this project could lead toward desktop linux taking a huge hit 
in the security sector, and thus a huge hit overall in the PR sector.  
SOME widget will have to do everything it can to make sure that nothing 
a user installs will allow him to elevate his privileges.  Otherwise the 
added security part is moot.

>
> 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.

I can imagine the intent, but I think the private install concept 
introduces far more implementation problems than anything.  For one, 
you're really going to play havoc with rpm databases.  For another.. see 
my other comments to the whole group. 

>
> 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 

and also may end up with the same exact application installed multiple 
times with nothing gained but extra used hd space

>
> - I can install something which I want other users to not be able to 
> access 

on a home syste.. why?

>
> - I can install a conflicting version of a program for myself 
> (binaries aren't usually versioned, so this is sometimes a problem) 

I would consider this to be a special situation, not necessarily worthy 
of consideration for a broad RFC

>
> - 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.) 

Generally no.  labs and office jobs aren't going to want people 
installing private stuff on that level.  The situations where that WILL 
be allowed are going to be very specific, and probably SHOULD require 
some work on the user's part.

>
>
> 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.

I understand and guessed as much, but that doesn't make it worthy of a 
far reaching desktop standard.  Standards aren't supposed to be 
'suggestions'.. if TCP/IP were merely a suggestion, no 2 networks could 
be assured to be able to communicate.  This means the standard should 
encompass what will cover the most likely scenarios.  Then, if 
distributions want to implement private installs on their own, that's 
another issue.

>
> 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. 

Well, the directories may be, but you're going to have a bunch of 
package databases, broken menu entries and icons, etc, left laying 
around if the directories are simply deleted.