XDG_SESSION_TMPDIR

[Lennart Poettering]

On Wed, 28.04.10 21:40, Ryan Lortie (desrt at desrt.ca) wrote:

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

Well, these are certainly valid, but the point I was trying to make is
that if XDG_SESSION_RUNTIME_DIR is not set brokeness on NFS is still
preferable over general brokeness of the various homegrown algorithms
people might come up with (and already came up with) to get a session
scoped dir beneath /tmp.

Systems with NFS $HOME tend to be administrated centrally, and hence
relying on the admin to set XDG_SESSION_RUNTIME_DIR properly might not
be asking too much, and most distributions will set it anyway via CK...

But anyway, I can see that this is a bit of a dilemma, either way we go,
some things will be broken. And given that XDG_SESSION_RUNTIME_DIR would
probably be set more often that not, it is probably a peripheral problem
not worth discussing into much detail. Either wording should be
fine. The one preparing the patch for the spec wins, i.e. you. ;-)

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

Well, as mentioned elsewehere I am actually now in the camp of those who
want to tear down the clear seperation betwen multiple concurrent
sessions of the same user, and instead move to a different definition of
a session, where it is a thing that is shared between multiple
simultaneous logins and ref-counted by them.

Should there be consensus that that is the way forward, then the
session-scope/user-scope distinction for the purpose of
XDG_SESSION_RUNTIME_DIR would mostly go away, too.

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

I like xattrs.

Leases are evil. Mandatory locks too (but not even an issue, since iirc
they require root privs anyway)

inotify, xattrs, leases, mandatory locks are all Linux specific. We'd
need to find some language there to not piss of the people who work on
other OSes.

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

Well, if we'd move to this new definition of a session pointed out
above, then /some/path/desrt would be just fine.

The XDG_SESSION_COOKIE is intended to be used as session identifier. If
it is cumbersome to use because it is too long, then this should
probably be something to fix in CK. I don't think any spec for
XDG_SESSION_COOKIE was ever written and the string in my understanding
should just be considered an opaque blob of chars. That means we could
simply change it so that it is generated from the PID of the login
session process plus the machine id, and hence becomes more handy to
use.

Or in other words: not using the XDG session cookie for naming that
directory smells like a workaround to me. I'd rather see the root of the
problem fixed than a workaround added here.

That all said, in the end how XDG_SESSION_RUNTIME_DIR is actually
generated is an implementation detail, the same way as
XDG_SESSION_COOKIE. In fact they both would be set and controlled by CK,
and hence we could just leave open in the spec how the path is built as
long as the result is a private namespace and provides the features
mentioned.

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

I think you want Jon.

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

Well, this is a good argument for tearing down the strict seperation
between concurrent sessions (and their lifecycles) of the same user.

If we'd just say that a session is active as long as the user is somehow
logged in, on one or more displays, via SSH or X11 or whatever (and
possibly even include user cron jobs in that), then we could solve a lot
of stuff that currently hasn't been clearly solved. We'd have no need
for a user bus, and could keep these xdg dir spec changes minimal.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4