"Local" data in home directories

[Joerg Barfurth]

Hi all,

The recent discussion on home directories (and subdirectories) on this 
list reminded me of an issue I have encountered repeately in recent times.

There are several occasions where I need a local place to store per-user 
data. I'll explain what this mean and try present a suggestion how to 
address this requirement.

Any comments are welcome.

+++++

"Local" here occurs in two different meanings:

(A) a physically "local" file system. The underlying requirement is that 
this file system offers high performance. So a local disk would be nice 
and NFS over a WAN would be undesirable.

(B) a "private" location that is unshareable between hosts.

These two meanings are related in that per-host storage is typically 
placed so it can be accessed performantly from the host, and that 
conversely the most performant and efficient file systems are often 
those directly attached to a host, so they can easily be configured to 
offer private storage.

In the FHS similar characteristics are typically needed for /var. But 
/var is typically not writable for users. The closest approximation for 
the desired semantics is probably offered by /var/tmp.

+++++

I need such a place for the following kinds of data:

1. user settings that are host specific (-> requires (B))
There are various preferences and other settings that are specific to a 
certain host,site,architecture,etc.. This includes (but is not limited 
to) settings involving absolute file pathes or that are related to the 
identity or network location of the host.

Storing this data in a well-known location in the home directory breaks 
scenarios where a NFS home directory is shared between hosts, archs and 
OSes.

2. local replicas/caches of user data and configuration that are 
available on a large network or the internet (-> requires A)

This concerns e.g. application caches (e.g. of internet files). One 
scenario which I encounter sufficiently often has a shared/networked 
home directory, which is accessible widely but can be rather slow in 
return. In such a case caching to that home directory misses the purpose 
of the cache - namely to avoid the slow, inefficient network access for 
repeated accesses. There may even be cases where I want be able to 
create a local replica of something in the home directory to ensure fast 
access. There are other cases where the slow resource is e.g. a databse 
or LDAP server. Note that such replicas may not only be needed for 
performance reasons, but also to enable offline operation.

3. A combination of 1. and 2.: data that is derived from a network 
resource and modified in a host-specific way.

I don't have a good example of this yet, but I'm working on stuff that 
needs this :-o

Only for (2) there is a usable place now, namely /var/tmp. But using the 
'raw' /var/tmp has some problems of its own. Two that come to mind are 
security and namespace. Every client dealing with user-specific data in 
a world-writable location has to do things properly to maintain privacy 
and security. And naming schemes that avoid collisions when multiple 
users and applications are sharing such a space are difficult to find 
and enforce. Additionally the requirements and schedules for occasional 
deletion of temporary files of system-wide services from /var/tmp may 
not apply to semi-temporary per-user data. For example, things that are 
replicated for offline use should not simply be deleted. Thus mixing 
these two categories in one location makes administering the location 
harder. Summarizing: even in this case /var/tmp is not a good solution.

+++++

Some additional considerations:

- Many current applications don't distinguish properly between 
user-specific data that should follow the user whereever she goes and 
'local' data. But then this couldn't be done easily so far, because 
suitable interfaces were not in place. Of course fixing all the 
applications will take time, but we need a usable interface now just to 
enable this.

- Others apparently had similar requirements: MS Windows offers a 
"LocalSettings" subdirectory in each user profile, which does not roam 
with 'roaming profiles'.

+++++

My proposal:

- There needs to be a defined (dot-) location within $HOME that is 
considered unsharable (between hosts, as defined in the FHS spec).

My preferred naming for this would be $HOME/.local. Unfortunately this 
interferes with the XDG basedir spec. I would like to hear alternative 
suggestions. I don't really like $HOME/.var, but it could be a last resort.

This location is the interface used by software that needs a location 
for per-user data that either is unsharable (B) or that is performant 
(A) and need not be shared.

- There is an optional unsharable directory in the file system 
hierarchy, into which user-specific subdirectories should be placed. I 
suggest using /var/users.

If this location is used, then $HOME/.local should be a link to the 
corresponding subdirectory of /var/users (e.g. /var/users/$USER).

- There needs to be a tool to properly and securely set up the user 
directories in /var/users (and the links). Probably this should be 
hooked into useradd/usermod as an extra option. I haven't thought about 
this very deeply yet, so I'm open for suggestions.

+++++

Conclusion: I am aware that my proposal should also be discussed on the 
FHS lists. As all my requirements originate in the sphere of desktop 
applications and as this interacts (or interferes?) with the XDG basedir 
spec [*] I wanted to get some discussion here first.

[*] Unfortunately I could not recheck the basedir spec as I wrote this, 
due to the site outage.

So all kinds of flames, comments and suggestions are welcome.

I'd appreciate to hear if other people have similar needs. I'd also be 
glad to hear that another solution for my issues already exists or has 
been proposed.

Regards

Joerg

-- 
Joerg Barfurth              Sun Microsystems - Desktop - Hamburg
 >>>>>>>>>>>>>>>>>> using std::disclaimer <<<<<<<<<<<<<<<<<<<<<<<
Software Engineer                         joerg.barfurth at sun.com
OpenOffice.org Configuration          http://util.openoffice.org