XDG_SESSION_TMPDIR

[Ryan Lortie]

Hi Lennart

Thanks for the feedback.

I'll reply to your main points only, pretty much all of which I agree
with.

On Sun, 2010-04-25 at 03:44 +0200, Lennart Poettering wrote:
> I think instead of doing a seperate spec it would be more appropriate to
> update the XDG basedir spec, however.

I agree.  This is a good fit.  Also, less work. :)

> I'd argue that XDG_SESSION_RUNTIME_DIR is a more appropriate name, since
> I think the data you pointed out above is more like /var/run than it is
> what /tmp should be used for. 

Right.  This really is quite a lot more like /var/run than /tmp.  Your
proposed name works for me.

> Hmm, they way I envisioned XDG_SESSION_RUNTIME_DIR I would actually
> would have mandated that the fallback is $XDG_CACHE_HOME, and hence
> ~/.cache (or some subdir of that). It would then be up to the admin to
> guarantee that ~/.cache is a directory capable of AF_UNIX sockets and
> POSIX locking and the like, if he chooses not to set
> XDG_SESSION_RUNTIME_DIR.

I don't like this for a couple of reasons

  1) user's homedir might be on NFS
  2) user's homedir might be on NFS

in more detail:

  1) things like mmap(), rename semantics, etc may not be reliable
  2) we could end up sharing the directory with another session
     [technically we have this risk on non-NFS too if we support
      multiple sessions on one machine]

My idea was that if this directory is missing some fallback would occur
like some sort of manual negotiation over D-Bus for an appropriate place
to drop files.

> Well, for the PA case and most other user software I can think of that
> currently puts a socket in /tmp (i.e. ssh-agent, and suchlike) is
> actually more interested in a per-user than a per-session dir.

I'd argue that ssh-agent is more usually considered to be
session-scoped.  Also: tying this to a session gives nice guarantees
about the directory being empty on login and corresponds with the
lifecycle of a session D-Bus.

> I'd also mandate that it is capable of accepting AF_UNIX sockets as well
> as that it is capable of POSIX file locking, and imposes no limit on the
> charset for filenames. Also I'd recommend (but not mandate) that every
> possible file system feature the OS supports is available on the dir
> (xattrs, ...).

xattrs seems unnecessary.  Good things: sockets, fcntl locks, inotify,
no file naming restrictions, normal rename semantics, mmap without
glitches, leases on Linux, etc.  I'd also maybe specifically mention
that mandatory locking is not supported here (since mandatory locks are
really dumb anyway).

> > Creating the directory on a memory-backed filesystem is preferred simply
> > because it's faster.
> 
> Well, that's an implementation detail, and I am not sure it even is
> true. Also, on 32bit archs using tmpfs is a bit problematic in some
> cases, since the limited address space also limits the size of the
> tmpfs. I'd not mention that in the spec.

It was mentioned in the "implementation" section of the spec. :)  If
this is in the basedir spec, however, I guess we can avoid discussing
implementation.

> Hmpf. What I had in mind here is actually have something that is
> enforced by CK when creating a session. I.e. on login, create a directory
> /var/run/users/lennart-$XDG_SESSION_COOKIE or such like, which is created
> and removed by priviliged CK code, and hence needs no complex locking or
> privilege control. By doing management of that dir from priviliged code
> things would become a lot simpler, since we can actually enforce policy
> on it.

My only concern here is unnecessarily long directory names.  I'd really
prefer a name such as /some/path/desrt or /some/path/session:desrt if
there is only one logged-in me.  Failing
that, /some/path/session:desrt.1234 (for pid 1234 as part of the login
process) is good.  I'd argue that long names waste memory and reduce
performance but the real reason is that they're just plain ugly and
programmers and sysadmins will no doubt have to manually deal with them
from time to time.

> Distributions should probably mount the entire /var/run as tmpfs, and by
> putting these user dirs beneath that hierarchy we'd just inherit from
> that.

That would be fine by me.  /var/run/session/____ has a nice ring to it.

> > Periodically a cleanup process can run to check that there are no stale
> > session directories (ie: by trying to acquire the lock on them and
> > deleting them if they are unlocked).
> 
> Well, that's probably something CK should take care of. I am no fan of
> periodic cleanups.

If we have some system-level process that's not subject to being
negatively impacted by ungraceful session exits then it's certainly true
that we can avoid the 'periodic cleanup' thing.

> > I used /dev/shm since that's a world-writable tmpfs that's available on
> > most Linux boxes these days.  I don't know if that's a good idea, but it
> > works.
> 
> Well, I think something below /var/run/ is more approproate.

I agree.  My hack was just a hack. :)

> > In order to use this, just create a file in /etc/X11/Xsession.d *after*
> > where D-Bus gets launched (ie: higher number) containing:
> 
> >   STARTUP="/path/to/xdg-session-tmpdir $STARTUP"
> 
> Meh, chaining processes like this (and ssh-agent, and dbus-launch)
> enforces serialized startup. Please stop coming up with systems like
> this. It's evil.

If we put it into CK then things are happy.

> > Pending discussion/flaming, I'll write this spec up properly and create
> > a git repository for a simple implementation (which may or may not look
> > like the one I've attached here) and start doing releases.  After that
> > it should be fairly trivial to vendors to start providing this.
> 
> My recommendation → integrate this into the XDG basedir spec and into
> CK. Don't write a new spec, don't write seperate code for this.

I'm CC:ing David onto this discussion.  Let's see what he thinks.

> Well, stuff like ssh-agent and the like allow people to share ssh keys
> between their logins. I'd really try to cover for this use case.

I've always thought that we should have some very
simple /var/run/user/desrt/ type thing for each user on the system.  The
sort of thing that you suggest with ssh-agent, though, is difficult to
contemplate.  What is the lifecycle like?  Until reboot?  If it's "so
long as 1 or more sessions are logged in" then how do we detect when the
last sessions logs out and kill all the processes that are appropriate?
Again, I find myself considering the multiple-session case slightly
fringe and possibly not worth the added complexity.


Thanks for the reply

Cheers