mzkqt at 0pointer.de
Mon Dec 24 03:31:11 PST 2012
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
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 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 Poettering - Red Hat, Inc.
More information about the xdg