[systemd-devel] /run DoS

[Lennart Poettering]

On Mon, 09.05.11 23:31, Karel Zak (kzak at redhat.com) wrote:

> 
> On Sun, Apr 03, 2011 at 11:45:51PM +0200, Kay Sievers wrote:
> > 2011/4/3 Lennart Poettering <mzerqung at 0pointer.de>:
> > > On Sun, 03.04.11 23:28, Michał Piotrowski (mkkp4x4 at gmail.com) wrote:
> > >
> > >> > But for /dev/shm I see no quick fix... do you?
> > >>
> > >> Unfortunately not. No one foresaw that quota support on tmpfs will
> > >> someday be useful :)
> > >>
> > >> >
> > >> > I think we should fix either both or should wait for the proper fix by
> > >> > the kernel.
> > >>
> > >> Can you temporarily fix one?
> > >
> > > Well, of course we could.
> > >
> > > But, think about it, what does this help? The vulnerability doesn't go
> > > away by doing this, and we'd have a temporary hack in there, that we'd
> > > have to remove later on again.
> > 
> > Systems who might run into problems with /dev/shm, can just add limits
> > to /etc/fstab, and systemd will re-mount it and apply them.
> > 
> > There should really be a _proper_ solution some day, be it quota or
> > something else. We have way too many /tmp-like dirs, where users can
> > just leave their crap behind and cause problems. This is really
> > nothing new with systemd.
> 
>  Wouldn't be possible to use namespaces (pam_namespace ?) and after
>  user login create any private tmpfs (with explicitly defined size)?
> 
>  This allows to use the same path (e.g. /run/user) for all users, make
>  the content of the directory invisible for other users and
>  effectively control resources. All this is supported by kernel ;-)

Well that's difficult for /dev/shm, since the way it is defined it is
system global.

And for /run/users it has been proposed to mount a tmpfs into the
per-user dirs, and we could do this pretty easily. However, since this
only fixed part of the problem and having gazillions of tmpfs lying
around, one for each logged in user we thought we better wait for a
proper solution which is quota, or something similar.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.