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

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

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

Also, note that this is not intended for server installs, as is stated in the proposal.

Thank you for the feedback.

Hope this helps

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Saturday 27 March 2004 06:11 pm, Nicolas Mailhot wrote:

Le sam, 27/03/2004 à 17:34 -0500, Gary L Greene Jr a écrit :

...

This is a proposal for a standard to accommodate the accessibility of the filesystem by end-users. We request discussion on this as a new standard. The URL to get to the document is:

http://www.csis.gvsu.edu/~abreschm/uafhs/

From a usability POW hidden files (and directories) are very bad. I must admit I'm a bit horrified by the number of new hidden roots you're suggesting to create (not only you duplicate classic / topdirs but you also enshrine stuff like fonts that doesnt exist on the system root).

I was under the impression that ~/.fonts was added as an X standard, from font config tools.

My proposal would be simple :

1. use a single or at most two-three top-level dirs in ~ (etc and the

rest)

Which others would you remove? The only one that I thought was not neccesary was config, and that deals with your third point as it helps clear the current clutter.

2. at this point you can probably not hide them since they won't result

in too much clutter

If it is meant to be a standard, they cannot be renamed. If they aren't hidden now, they never will be.

3. do not try to keep current dotfiles/dotdirs in your spec but move

them to your clean file layout

Hidden files are sometimes, but not always, bad. One of the suggestions was that a distribution should create an interface to this, just as they do to the current installation directories. The reasoning is, and please feel free to critique, that interfaces to program installation change day by day and are constantly improving, so a long-term standard should not be involved in them.

Also, when do you actually look in /bin/ ? It's really not a place to be looked at directly. The problem is that users only have access to their home directories, so they can't put it somewhere they won't be looking. Hence, the hidden nature of the directories.

As far as I know current $HOME clutter is what's keeping some people from using it as their desktop (even though that the natural unix way). Cleaning up the mess would certainly help there.

A good point is the way you follow / FHS layout instead of reinventing yet another convention.

Anyway - I'm pleased to see someone working on this ! Most people seem to have given up on ever cleaning up the home legacy dotfile mess.

Regards,

Thanks for the input.

- -- Gary L. Greene, Jr. Sent from uriel.gvsu.edu 6:36pm up 5:50, 5 users, load average: 0.32, 0.17, 0.19 ============================================================ Volunteer developer for the Ark Linux Project check out http://www.arklinux.org/ for more info. Also http://www.csis.gvsu.edu/~greeneg/ PHONE : (616) 331-0849 EMAIL : greeneg@arklinux.org ============================================================

On Mon, 2004-04-05 at 06:53, Rui Miguel Seabra wrote:

On Mon, 2004-04-05 at 16:39 +0300, Doncho N. Gunchev wrote:

...

I really dislike all these hidden dotfiles/dotdirs in my home directory

and am happy to see someone is working on this. I was thinking it would be better if we had ~/etc/bashrc instead of ~/.bashrc and so on, but I see much more general ideas here, so here's what I think looking at it:

~/{bin|etc|...}/ is a lot worse than ~/.{bin|etc|...}/

But what's really good is to have:

~/.YouNameIt/{bin|etc|...}

YouNameIt could be something like 'myapps_root' whatever.

I think a ~/.distributionName/{bin|etc|...} doesn't make a lot of sense.

I personally don't like the idea. If I want a bin directory in my home directory - export PATH=~/bin:$PATH

The problem I see is security. A virus can not alter binaries it does not have permission to alter, and that is why binaries, config files, default templates, etc. should be installed with root ownership by the root user.

Another issue is dependency resolution. Either everything in these directories is going to have to be static linked - or when the user upgrades their system they are going to have broken binaries, and that's no fun at all.

Another issues is updates - they will not be able to be managed by the central system update system. In win XP - I hate having to launch an application in order to check for updates - but this is the case with most of the non MS apps on that system.

I think a better solution is simply to make it easy for end users to use the facilities of yum or apt or whatever the distro has implemented.

Put in a cdrom and the repository of packages gets added to the package management facility for the purpose of installing the software on the CD (and at the same time grabbing needed dependencies from the distro repository). It can add the PGP sig for the vendor as well, and add the vendors update repository - so that there still is one app that a user needs to use to update all software on their system.

Yes - it means knowing the root password to install software. Cry me a river. It's the right way to do it, encouraging users to install software in their home directories is imho a recipe for disaster. That should only be done by developers who are testing their code, and know how to launch an app that isn't in their path.

On Mon, 2004-04-05 at 07:17 -0700, Michael A. Peters wrote:

I personally don't like the idea. If I want a bin directory in my home directory - export PATH=~/bin:$PATH

The problem I see is security. A virus can not alter binaries it does not have permission to alter, and that is why binaries, config files, default templates, etc. should be installed with root ownership by the root user.

I fully agree with you. I'm just trying to minimize some design problems.

Another issue is dependency resolution. Either everything in these

Another issues is updates - they will not be able to be managed by the

Perfectly reasonable. It's just a matter of "creating a standard" way to do this, but this clearly isn't for joe newbie anyway.

I think a better solution is simply to make it easy for end users to use the facilities of yum or apt or whatever the distro has implemented.

Yes. +++++

Yes - it means knowing the root password to install software. Cry me a river. It's the right way to do it, encouraging users to install software in their home directories is imho a recipe for disaster. That should only be done by developers who are testing their code, and know how to launch an app that isn't in their path.

I don't understand why, but people seem to think one should be able to do advanced things and not know what one is doing. _This_ is a recipe for disaster. If it's joe newbie don't make it easy for him to install "untrusted" software, make it easy for him to install software from "trusted" sources. For this you need a fairly large resource pool and an easy way to install software.

Strangely enough, many think GNU/Linux has few software, and say it looks like Windows when a full install occupies several gigabytes.

What they don't usually notice, which is strange for me, is that seldom do they need to install foreign software. There's no need for an "installer" like Windows has since our installers are way better (rpm, deb + metapackagers like apt, yum, etc...).

It's a problem of education!

Rui

On Mon, 2004-04-05 at 11:30, Doncho N. Gunchev wrote:

On Monday 05 April 2004 17:17, Michael A. Peters wrote:

...

... I personally don't like the idea. If I want a bin directory in my home directory - export PATH=~/bin:$PATH

The problem I see is security. A virus can not alter binaries it does not have permission to alter, and that is why binaries, config files, default templates, etc. should be installed with root ownership by the root user.

A virus/worm can damage only files owned by the user, so with

or without binaries owned by the user who has run the virus/worm in her/his home, it can make the same damage. A virus/worm can make ~/.bin and also export PATH="~/.bin:$PATH" from your ~/.bashrc. What's the diference? The only way to stop the user from running untrusted applications is to mount /home and /tmp with noexec, which breaks some applications (rpmbuild, mc) :(

But if the system allow an user to install shared applications without any kind of authentication, a virus or worm can access the files of any user, or it can start key loggers or any other garbage

...

...

-- Regards, Doncho N. Gunchev Registered Linux User #291323 at counter.li.org GPG-Key-ID: 1024D/DA454F79 Key fingerprint = 684F 688B C508 C609 0371 5E0F A089 CB15 DA45 4F79

On Mon, Apr 05, 2004 at 07:17:10AM -0700, Michael A. Peters wrote:

I personally don't like the idea. If I want a bin directory in my home directory - export PATH=~/bin:$PATH

This is already the default in Fedora Core, BTW> Mirek

On Mon, 2004-04-05 at 18:08 +0300, Doncho N. Gunchev wrote:

...

The advantage of having this in a single directory is, for instance, sharing.

You can not share binaries from diferent distributions or even

diferent distribution versions sometimes.

Right. I must've lost or skimmed too much some email.

That is the idea of having ~/.younameit/arch/distro-ver/bin. If you check

...

BUT STAY AWAY FROM STUPID VISIBLE DIRECTORIES IN ~/ (oh well, maybe in this case one can tolerate a visible ~/YouNameIt since not only you're not forced to use it, but also there might be an interest in using it, just don't add a few couple of hundreds of uselless directories in the desktop.

I prefer many visible configuration files in configurable base

directory instead of many hidden configuration files in my home directory.

They are visible, just very seldom used or touched, and they fill with useless clutter desktops in ~/ which is much more user friendly than brain-dead-Windows-alike ~/Desktop/ . We don't need this folder, we _are_using_ an operating system designed for multi-user perspective, but that is a discussion for another list/thread.

Rui