[systemd-bugs] [Bug 75566] RFE: make /run/user/$UID tmpfs of its own

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=75566

Lennart Poettering <lennart at poettering.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|tmpfs sizes, specifically   |RFE: make /run/user/$UID
                   |for /sys/fs/cgroup          |tmpfs of its own

--- Comment #1 from Lennart Poettering <lennart at poettering.net> ---
A tmpfs doesn't take up any memory if it is empty. Write access to
/sys/fs/cgroup is restricted, it is not world-writable. Only root can write
there. If you are concerned about the resources root might consume, then, well,
there are bigger fishes to fry.

The tmpfs size= parameter is a limit that is useful for world-writable (or at
least user-writable) mounts, and otherwise not too interesting.

/dev/shm/ is world-writable. /run is not (well with the exception of /run/user,
but we are working on mounting /run/user/$UID as tmpfs that is lifecycle
tracked by logind). Hence /dev/shm really should come from a different pool
than /run. Hence you really should mount things seperately. And that's what
systemd does. If you don't mount them seperately you basically invite
unpriviliged users to fill up /run thus blocking system services to work.

/dev/shm and /tmp are security problems since they know no per-user quota (and
also are a shared namespace). That means that a user can fuck with another user
on the same system. THis has been brought up a couple of times to the kernel
guys, there have been patches to add quota to tmpfs, but so far nobody really
cared too much to put enough pressure on it to push it upstream for good.

There's no point in turning /run/lock into a tmpfs of its own. It's a moronic
interface anyway, and should be phased out. Also, it should be considered one
user of /run like any other. 

Summary:

a) the size= param is just a limit, as long as nobody uses the memory it
doesn't matter. It doesn't allocate anything when you pick a larger value, it
just puts a limit on allocation within it.
b) /dev/shm and /run on the same tmpfs is really dumb, actively makes things
less secure
c) adding size= to /sys/fs/cgroup doesn't hurt, but doesn't bring benefit
either
d) we should introduce separate tmpfs mounts for /run/user/$UID, this would
actively make things more secure
e) /dev/shm and /tmp are simply badly designed since no quota is applied and it
is a shared namespace

I'll now rename this bug to request item d), if that's OK with you, since that
is the only thing that would really be a benefit i think.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-bugs/attachments/20140227/b6cc5750/attachment.html>