[systemd-devel] [PATCH 1/2] Don't clean /var/lock/subsys or /var/run/user; they're not aged content.

[Lennart Poettering]

On Tue, 26.10.10 10:33, Bill Nottingham (notting at redhat.com) wrote:

> 
> Lennart Poettering (lennart at poettering.net) said: 
> > > I was looking for non-systemd users - while the user-specific dir
> > > is created, there's no actual data that ends up being written there
> > > (at least on my test desktop).  Perhaps none of the apps in that
> > > set are using XDG_RUNTIME_DIR?
> > 
> > XDG_RUNTIME_DIR is actually only something I have discussed with a
> > couple of folks and implemented it because I needed it in
> > pam_systemd. However, there's no official documentation for it, nor have
> > I ever proposed it to the xdg mailing list, since there's a bit of a
> > uncertainty whether XDG_RUNTIME_DIR should be bound to the individual
> > sessions or to "first session to last session of a user".
> 
> How does this differ from implementing (for example) per-user /tmp?

In a number of ways:

- Primarily it is nearly impossible to use /tmp safely to place a communication
  socket in: on one hand you need to establish a non-random name, so that
  client and server find each other. On the other hand you must choose a
  random name to avoid DoS vulnerabilities that some other user might
  take away your names in /tmp and all your software doesn't
  break. (With major hacks one can work around this, but it's awful and
  almost nobody gets it right -- I did it in PA, and I am not proud of it)

- The lifetime of XDG_RUNTIME_DIR is strictly bound to the user
  actually being logged in. i.e. pam_systemd removes the dir when you log
  out. /tmp doesn't have that.

- The idea is that XDG_RUNTIME_DIR actually makes guarantees that stuff
  like POSIX locks and AF_UNIX sockets work properly and reliabl,
  i.e. is a real file system, and not NFS or so. For /tmp such
  guarantees do not exist.

And I think there was more, but they escape my mind right now.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.