Fwd: $XDG_RUNTIME_DIR

[Lennart Poettering]

On Mon, 24.12.12 10:36, David Faure (faure at kde.org) wrote:

> > Well, this is a DoS. You cannot use a guessable name in /tmp.
> 
> I see no other solution, as long as some distros don't set XDG_RUNTIME_DIR.
> (and BTW /tmp/.X0-lock is just as guessable, and has always been
> used.)

The X11 directories in /tmp are special, as sane distros create them
during early boot, so that the names are reserved and DoS issues do not
arise. That said, they are still ugly and X should use /run instead.
> 
> When talking to Debian people about setting XDG_RUNTIME_DIR, they pointed out 
> that another DoS attack is to fill up the partition containing XDG_RUNTIME_DIR 
> (e.g. filling up your /run/user/$USERNAME), preventing other users from 
> creating files under their own /run/user/$OTHERNAME. Is there a way to solve 
> this?

This is not an issue specific to /run. This is an issue to all
tmpfs directories, including /dev/shm and /tmp. 

We need quota on tmpfs, this has been known since long time, but there
is no need to fix this specifically for XDG_RUNTIME_DIR, but should be
fixed for all tmpfs instances.

A hack to add quota to /run/user is to mount a tmpfs for each user as he
logs in, which can then have a size limit attached. I think we should
avoid that however, since this would not solve the issue for /tmp and
/dev/shm, and is not applicable there, since users do not have private
subdirs there, but things are a shared namespace.

So, yeah, the issue exists, but needs to be fixed in the general
case. It's a limitation of tmpfs, not of XDG_RUNTIME_DIR. It's solvable
in the XDG_RUNTIME_DIR case, but we suggest to fix it properly in the
gernel tmpfs case instead.

> Finally, a last issue that came up about XDG_RUNTIME_DIR (when talking to 
> Debian people), was that it's not per-X-session ($DISPLAY), so logging in more 
> than once will break. A solution is for each application using XDG_RUNTIME_DIR 
> to create a subdir named after the DISPLAY, but it would have been nice if 
> this was handled by the OS automatically.

Well, placing per-session data in something that is per-user is easy
(just include some session ID in the file name), but placing per-user
data in something that is per-session is impossible.

Also, it's an illusion to believe our desktops could deal properly with
multiple sessions at the same time for the same user, so I think this is
mostly a theoretical issue...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.