Re: [RFC] User Accesable Filesystem Hierarchy Standard

>From: Zackary Deems <zdeems-tClYnr7/[email protected]>
>Subject: Re: [RFC] User Accesable Filesystem Hierarchy Standard
>Date: Mon, 29 Mar 2004 11:57:56 -0500
>
>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.

I do not see how having the directory structure installable by an RPM aids 
in anything. Of course, if you want ArkLinux to have such an RPM, you can 
easily make one.

If you are talking about choosing where to install something when a program 
is installed, that should just be an option they choose while installing the 
program, one of several installation targets. That is up to the packagers 
and is currently doable with standard RPM options (I believe, I am not a 
packager but this is what I have been told).

Such an issue simply does not belong in a specification of the directory 
structure. A system with the directory structure complies with that 
standard, and a system without the directory structure does not. Some 
distros may want it to be the default, others may want it to be in a tack-on 
RPM.

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

I truly don't think it adds problems. It means that individual users have 
privacy. Whether or not they want to use it is up to them. And, if you are 
worried about how children might install things for parents, you should 
consider that a distribution should support account management which allows 
one user to have control of another without being the root user, so parents 
would still have access to their children's files.

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

This in no way allows privilege escalation. You still need to be root to 
SUID something for privilege escalation. If not, any program installed in a 
user's home directory would be a local root exploit already.

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

I hadn't considered what this would do to RPM databases. I'm of the opinion 
that they should be able to cope with users having private programs, but I 
well understand that they don't and likely won't in the foreseeable future. 
That is the best argument against this so-far.

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

But it would still gain the other benefits. HD space isn't the primary 
issue. On modern system, installed programs are usually a small portion of 
HD space.

>>
>>- I can install something which I want other users to not be able to 
>>access
>
>on a home syste.. why?

Parents have programs their kids shouldn't touch, One person has a program 
related to work, A kid has a program used for school-work. I can think of 
many reasons which I and others would have used in the past.

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

Well, it may not be common, but it does happen and it would still be a minor 
benefit.

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

In many cases, they won't allow this. In which case, they shouldn't set it 
up. Of course, if they do want to do it, their choice of course, it 
shouldn't be hard to do.

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

I'm not making it a 'suggestion'. I, and other people I know, would use the 
private installation feature. They may not be a huge portion of the 
population, but they are a notable portion. This is why I would like 
comments from more people. So far, you have reasons against and I have 
reasons for. I hate to make this sort of decision with only two people.

Could someone else please comment?

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

Obviously, if the programs were installed by RPM, they could be uninstalled 
by RPM.

If RPM is set up to be able to remove all programs that are dependent on a 
program when that program is remove (I don't know if it is, I use 
Slackware), that might be a reason for your distribution to add this as an 
RPM entry. However, that's a distribution's choice. The standard only 
defines directories.


Sorry, I think I repeated myself a couple times, but I'm rather tired and 
don't recall where I did so.

_________________________________________________________________
Get reliable access on MSN 9 Dial-up. 3 months for the price of 1! 
(Limited-time offer) 
http://join.msn.com/?page=dept/dialup&pgmarket=en-us&ST=1/go/onm00200361ave/direct/01/