On Sun, Apr 03, 2011 at 11:45:51PM +0200, Kay Sievers wrote: > 2011/4/3 Lennart Poettering <mzerq...@0pointer.de>: > > On Sun, 03.04.11 23:28, Michał Piotrowski (mkkp...@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 ;-) Karel -- Karel Zak <k...@redhat.com> http://karelzak.blogspot.com _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel