Home folder substructure

This project study is part of A vision of a new file system hierarchy . The goal of this part is to consolidate home folders which are spread over the whole file system hierarchy inside one more unique location - as far it would make sense. Means it doesn't have to be done with every user having a home folder. We don't want to go to the one or another extreme end here too.

All here is based on a Gentoo linux system - the user and folder names as well locations could differ against other *NIX like systems.

There are two points we have to consider and each point may or may not apply. With reference of  /etc/passwd  the user has

• an interactive login with authentication and shell access
• a home folder

The matrix shows all possible combinations:

The options 2 and 4 could be ignored. These combinations doesn't have a home folder. So basically there are two groups of users left:

• The first group are ordinary users (usually humans) with an interactive login. An interactive login includes shell access with authentication. Let's call this group A.
• The second group (usually services/daemons) doesn't have an interactive login, which excludes a shell ¹⁾. Let's call this group B.

Before we go on lets have a look at the superuser root. To be accurate we have to say the user with UID 0. But as the name root is common we will use it for the superuser with UID 0 further.

From the groups above root isn't different from the group A in general. The one thing we have to consider is that root's home directory have to be present at any time. There are use cases where the  /home  folder is a mount point. It is unimportant how  /home  will be mounted. But if the  mount  command fails for some reason, no home directories are available. Thus we will specify a separate home for root. This shouldn't be configured to be a mount point. But there is absolute no reason to use the location  /root  (in the root folder  / ).

This leads to the following suggestion of second level sub folders of  /home/  :

The abbreviations are just alternative folder names. We will use the short 4 letter abbreviations below (like in the examples in the table above).

Let's go a bit deeper into details. From more simple to more complex we analyze some thoughts behind and explain reasons. Remember the underlying operating system. For those who are convinced right now it is may be not of interest - they could skip it and move forward to virtual users.

Group A

This group is simply like before with having one additional folder hierarchy level. If  /home  was a mount point we use  /home/user  now. It is not recommended to mount  /home/root .

Some people may have an objection that an absolute path specification will be increased. In some cases they may have right. But there exists common solutions to reduce the usage of absolute path specifications. At the command line there is the  ~ , which specifies the home directory. In scripts it is - or should be - best practice to define a  $PATH  variable. After an interactive login the  $PATH  variable could be extended by  $HOME  through the login shell's config file. It is recommended to change  /etc/skel  accordingly.

Any more objections?

Group B

Against the other group this is a bit more complex. Let's start with an analysis of some background.

Comparison: home directories of services

Two typical services and their equivalent users are apache and ftp. Both are users for services which are similar in general: each service provides data access through a TCP socket. Both services can handle virtual users. And once more they are not part of the operating system.

1. Common usage is to have the home directory of the user ftp in  /home/ftp . That's initially not wrong, but as user ftp doesn't have an interactive login, but will be mixed up with ordinary users here.
2. Common usage is to have the http servers (let's say apache here) home directory in  /var/www .
   1. In case of a static website why it is in the location for variable data?
   2. What is the difference against the ftp user? Doesn't ftp data behave/change different (more often) than www data (or: why not  /var/ftp )?
3. To go one step further: Why have the user p2p typically its home in  /home/p2p ? Aren't there variable data?
4. An another: fcron has its  crontab 's per user in  /var/spool/fcron/ . Are these variable data or config files (like with other cron daemons)?

The folder  /var  is considered for variable data of the operating system. A group of people in the *NIX world did spot this and stated that  /var/www  is simply the wrong location.

A small sidestep: In the second half of the nineties djb published publicfile. It was providing (outgoing) data for ftp and http by using one home directory for the data (with sub folders).

All these shows up small but existing inconsistencies, which should be reduced.

Using /home/srvc or not

Not every user for a dedicated service have to have a home directory here. An example for this is the ntp user. Or more general: users with an entry /dev/null in the home field of  /etc/passwd  doesn't need a home directory here. For sure there are exceptions. It should (have to) be deliberated which users require a home directory here - some points for a decision could be:

• separate OS relevant data from user application data
• don't spread data which belongs together over different locations

It would go to far for now to analyze every more locations here. A good starting point is perhaps to clean up the  /var  directory. One more example what could be considered to move is bind. Similar or against: what's about (ISC-)dhcp - even with a defined home it is more similar to ntp. At least there is no absolute right way to move to  /home/srvc . It have to be decided and defined case by case.

Roadmap

Against the 'Group A' there have to be considered to put data from different locations for a service together. Sub-folders could be helpful to have a structure. To stay with the initial example, apache's home could have the sub-folders  etc ,  log  and  www . The decision which services could/will be affected depends on multiple, different considerations. At the operating system level, usually there are to points which have to be adjusted. One is to re-configure the entries in  /etc/passwd . The other is to configure start processes to use the new location of the config file. Other perhaps required adjustments are at service level through the service's config file(s).

Summary

From the above, basically a folder structure under  /home  could be like this:

  /home ─┐
         ├─ root
         ├─ srvc ─┐
         │        ├─ apache
         │        ├─ mysql
         │        └─ ... 
         └─ user ─┐
                  ├─ foo
                  ├─ bar
                  └─ ...

This part is for the home folder only and have to be seen in a greater context of an investigation. There is no claim to cover all possible use cases and exceptions.

Virtual users

Virtual users are a special case. Common use cases are smtp and imap services, but there are more. Here we want to use the following definition:

The term virtual users defines users which needs a login/password for one dedicated service, but aren't allowed to interactive login to the system itself.

There is a dependency chain: a home belongs to a user and the user belongs to a service. Complexity will be increase if different services shares the same “home” for corresponding virtual users. This and other circumstances are beyond the scope here. It is a suggestion to link virtual user homes with the service.