The User-Accessible Filesystem Hierarchy Standard [LWN.net]

The User-Accessible Filesystem Hierarchy Standard is a proposed standard which has recently been put forward for wider review. The problem this standard attempts to address is: how do users of desktop Linux systems install software for their personal use without using the root password or hosing the system? The problem is real enough; as Linux shows up on more desktops, and more interesting applications become available, people will want to be able to do their own installations. Anything which can make those installations easier and safer should encourage desktop Linux adoption. It is not clear that this proposal will do the trick, however.

The UAFHS states that every user should have a directory (.system) in their home directory for the installation of personal software. This directory would have the usual subdirectories: .system/bin, .system/lib, etc. The placement of software there would contain it within one subtree and make it easy to find. The standard also suggests the creation of a .config directory under the home directory and moving all application configuration files there.

The next problem is that users of a shared system may want to install software for others to use as well. To that end, the standard says that /home/shared/.system should be available and writable for all users. The authors seem to have anticipated one of the possible complaints with this setup:

An additional concern regarding security is that all users will be able to easily install programs. This is not a security flaw, and is in fact a way to strengthen security. All users are already capable of installing software, it is merely difficult.

The argument here seems to be that, since the root password will not be required for software installation, the system will be more secure. The simple fact, however, is that making it easy for unprivileged users to install programs into the path of other users is not the best way to secure a system. This sort of mechanism could easily become a favored way of escalating access to a user account into a full root compromise.

This standard also fails to address the real issue. Unprivileged users who want to install software are not much concerned about where it is going to go. They will be far more interested in easy management of installed software. Mixing packages together into one big directory tree does little to help somebody who wants to get rid of things in response to the inevitable "no space left on device" or "quota exceeded" message. This standard says "put software over there," but does not concern itself with how users will actually manage that software.

Making software installation easier is a worthy goal. Part of achieving that goal can even be the designation of a target directory for installations. But anybody who wants to concern themselves with making this aspect of desktop Linux easier really needs to be dealing with the package management issue. Creating a version of rpm or dpkg which can do per-user package management could be harder than writing up a proposed standard, but it would do far more to address the issue at hand.

(Log in to post comments)

/usr/local/ ?

Posted Apr 8, 2004 8:46 UTC (Thu) by alspnost (guest, #2763) [Link]

Yes - it strikes me that having a group-writeable /usr/local, and putting select users into an "install" group, is a more elegant solution. That way, the group/user distinction still allows people to install programs that are usable by only themselves, only the group, or everyone....

/usr/local/ ?

Posted Apr 8, 2004 13:08 UTC (Thu) by horen (subscriber, #2514) [Link]

Yikes! This looks like a job for RBAC

Perhaps getting up-to-speed with SELinux is more mission-critical than many of us would care to admit; or, with the degree-of-complexity it possesses, perhaps creating the appropriate tools for administering it.

OTOH, I really do not want my desktop Linux users to be installing their own software packages. In the US Army, we had a saying: "The two most dangerous people are a Private with a rifle, and a 2LT with a pen." I'd like to add to that a PhD faculty member (w/ or w/o the root password).

/usr/local/ ?

Posted Apr 8, 2004 16:18 UTC (Thu) by tjc (subscriber, #137) [Link]

OTOH, I really do not want my desktop Linux users to be installing their own software packages.

Yeah. Whether a malicious program is installed in /usr/local or /home/share/.system doesn't really matter too much; the end result is about the same.

Also

Posted Apr 8, 2004 20:56 UTC (Thu) by Ross (subscriber, #4065) [Link]

Give /usr/local the sticky bit so people can't remove or rename other
people's software. And mount it nosuid,nosgid so people can't play tricks
with software that runs as them no matter who uses it.

My biggest fear is that this opens the door to spreading malicious
software. There is nothing to stop a user from adding a command named
"cp" which does rm -rf $HOME. Similarly this opens the door to viruses.
In the past they only affected people who already had infected executables
in their home directory or people who used a system where the root user was
running infected executables.

hidden directory

Posted Apr 8, 2004 16:25 UTC (Thu) by giraffedata (subscriber, #1954) [Link]

And why stick this stuff in hidden directories?

I find that people use hidden files/directories as a means creating another level of directory; i.e. all the dot files in a directory are effectively in a subdirectory so they don't clutter a listing of the main directory.

Frankly, I'd much prefer just to use the one directory hierarchy. It costs one subdirectory entry in a main directory to hide all the files that would otherwise be dot files.

I have taken the matter into my own hands somewhat: My alias for 'ls' includes the --almost-all option. That means I see the dot files even though the package author didn't want me to. I find I am much happier actually seeing all my files.

It does, unfortunately, make my home directory listing uncomfortably large, making me wish we had something like the .config/ standard mentioned in the article.

Don't hide it!

Posted Apr 13, 2004 14:17 UTC (Tue) by mwilck (guest, #1966) [Link]

And why stick this stuff in hidden directories?

Yes that is real nonsense. There are widely-used file managers out there that make it impossible to list hidden files, and there are file manager-writers out there who consider that a feature.

The User-Accessible Filesystem Hierarchy Standard

Posted Apr 8, 2004 13:08 UTC (Thu) by ordonnateur (guest, #6652) [Link]

As a system admin I really don't want users installing programs anywhere.
In practice nobody gets to touch the server but me, (except web pages in home directories - and that potential trouble enough).
As for the desktop, there are two catagories of user: those who know nothing, and will simply use what they have been given, and those for whom a little illusion of knowledge is a dangerous thing. The first group are not a problem, if things don't work for them then it is rightly my problem to fix.

The over-confident second group are the problem, and as has already been said , following standards is precisely what they wont do. So either there is a constant need to lock things down, and detect and prevent work-arounds, or accept it will happen and seek to sandbox the potential damage.
I find OSX seems to do something acceptable in this regard. Applications come in a readily identifiable package that stays in one bundle rather than scattering libraries and files all over the place.
Pehaps the cost is to have more application packages as static builds with no, or at least minimal, dependecies. The cost might be in terms of disk space and efficiency but desktops these days are ridiculously over specified for any sort of standard business use.

Users shouldn't install software?

Posted Apr 8, 2004 16:18 UTC (Thu) by giraffedata (subscriber, #1954) [Link]

As a system admin I really don't want users installing programs anywhere.

There are two models of the computer-user relationship. In one, the computer (along with its administrator) and the user are two cogs in a machine owned by someone else (an employer, probably). They are peers and there's no reason to expect the user to have any control over the computer.

In the other, the computer is a tool of the user. The owner of the computer and the system administrator are service providers to the user. In that model, there's no way to defend withholding from users the ability to install software per se.

Of course, in practice it's usually a nebulous combination of the two, leading to endless arguments.

Users shouldn't install software?

Posted Apr 8, 2004 18:53 UTC (Thu) by ordonnateur (guest, #6652) [Link]

Yes, that was the promise of 'personal computing': no need for a data centre and all those spoilsport admins, just go out and by the box and DIY.
And so long as it was just a glorified typewriter there wasn't much trouble with that. It saved the admin from a lot of trivia, it kept the end user happy. It was even, you might say, an advantage, when the users came cap in hand to the experts to fix thier spreadsheets and macros and bits of BASIC: teach them it's not as easy as they think.

But then came networks of document processors, and the spreadsheets started to look like the company accounts, and the order process on a db held together with string and sealing wax, not to mention email and all. The isolated PC is no longer isolated, and the users who do most damage are the ones with computing power in excess of thier aptitude and inclination to master it.
I can't do much about people who wilfully use a computer badly, other than protect my patch with defensive walls, but I do think it is a responsibility of distributors, developers, and sytem managers to think about the implications of a world of ignorant users. Dangerous machinery needs to have guards and covers over the moving parts, because anyone can slip sometimes, and many people are simply careless.

Users installing software for other users

Posted Apr 8, 2004 16:37 UTC (Thu) by giraffedata (subscriber, #1954) [Link]

I think what the proposal misses is that there need to be subsets of users. If a user is to install software for ALL other users, then he is a system administrator, and there's little to be gained by making him install his software some place other than /usr/local/bin.

But given a multi-user system, users might want to form groups. Everyone on a certain project, or in a certain department, maybe. Or maybe just everyone interested in a certain software package.

So the standard needs to provide an arbitrary number of public places for non-sysadmin users to install stuff that other users can get to. And those users need to be able to choose for themselves which of those places to include in their search paths and know that only certain stuff will end up in their search paths that way.

Multi-architecture problem

Posted Apr 9, 2004 14:29 UTC (Fri) by nix (subscriber, #2304) [Link]

The system I use to install software that the admins at work don't want to manage (of which there is plenty) is to stow things into a tree .packages/{config-guess-triplet}/ and .packages/all, putting arch-dependent stuff into the former, and arch-independent stuff into the latter. Both are then stowed into place (although there are extra complexities with LD_LIBRARY_PATH for shared libraries).

What can I say, it works, although a number of programs that don't implement the GNU Coding Standards properly (or at all) needed build-system patches to properly separate arch-dependent and -independent install trees.

The User-Accessible Filesystem Hierarchy Standard

Posted Apr 8, 2004 21:26 UTC (Thu) by strombrg (guest, #2178) [Link]

How about leaving things in a user's home directory, but having a database of which apps are available in which users' directories? Then there's an app that queries the database, with options like "add this one app to my path" or "add all apps installed by user xyz to my path". The option to "add all apps installed by any user to my path" might need to not be implemented, or perhaps be site configurable.

Also, it'd be really nifty if software could get its libraries and config files relative to an environment variable (or perhaps more than one env var, with one being site specific and one being app specific, with the app one overriding the site one, but most software going at the site one). So much software has compiled in paths, making it so you can't move it around without recompiling. If it were relative to an env var, then you could package it once, and you could just as well put it in /opt, or the user's homedir, or /usr/local, or any other local convention people might have chosen. Of course you'd have to default to Something if the env vars aren't set, or maybe error out.

Dan Stromberg, strombrg@dcs.nac.uci.edu

The User-Accessible Filesystem Hierarchy Standard

Posted Apr 9, 2004 2:12 UTC (Fri) by raytd (guest, #4823) [Link]

This standard also fails to address the real issue. Unprivileged users who want to install software are not much concerned about where it is going to go.

I very seriously doubt that this "standard" was written for that type of user. It appears to me the target audience are users installing from sources.

I'm having difficulty understanding the resistance of system administrators (that have spoken up) to users building/installing software in *their* own sandbox. (That said, I agree that nobody should be sharing files or directories within their home directory. There are other/ better/safer ways to achieve the same result.)

If a particular user is *that* dangerous", I believe you have bigger problems than he or she installing software compliant to a "standard".

Everyone I work with is fairly trustworthy and everyone has, or can get, super-user priveleges to boot. Can someone share with me what environments warrant such distrust? I really want to understand.

The User-Accessible Filesystem Hierarchy Standard

Posted Apr 9, 2004 14:34 UTC (Fri) by nix (subscriber, #2304) [Link]

(That said, I agree that nobody should be sharing files or directories within their home directory. There are other/ better/safer ways to achieve the same result.)

If those other ways require work as root, then I and many others working in places with grossly overloaded syadmins can't use them. It generally takes multiple years for the admins of the net at my workplace to act on a request to type a one-line command. Running stuff out of my $HOME, and providing scripts that let others use the same things, is the only practical option.

The User-Accessible Filesystem Hierarchy Standard

Posted Apr 9, 2004 21:03 UTC (Fri) by raytd (guest, #4823) [Link]

I was thinking of sharing data and/or code through /var/tmp, or something similar.

It just sounded to me as though some of these fellas have a full-time job thwarting crackers and script kiddies that have a *valid* login. I might expect that at a university, but I hope that's not the norm elsewhere.

Why hide the system and config dirs?

Posted Apr 15, 2004 15:24 UTC (Thu) by jalexstark (subscriber, #5742) [Link]

Absolutely. Linux is beginning to look like MS in this regard. Hidden directories are almost as annoying as hidden file extensions.

My home directory is a mess, and I can't clean it up.

Principles:
* Have one dir for config, one dir for Desktop, one dir for personal software, one dir for volatile (non-backup) stuff.
* Don't hide things as an excuse not to clean up a mess, eg configuration.
* Don't make things so simple for the idiot that lead to unnecessary confusion, eg file extension hiding.
* Make backups easy, eg provide a way of getting the browser cache out of harm's way.

I have solved these so far by creating multiple personal directories such as /home/tmp.joe as well as /home/joe.

I think that a good way forward would be to phase out $HOME and replace with $HOMECONFIG, $HOMECACHE and $HOMEMAIN, or something universally agreeable. It would be trivial for s/w to use these.

[This comment was provided with the support of a battery backup, ;)]

Alex