Bug#779902: /tmp can be mounted as tmpfs against user's will

[Martin Pitt]

Control: found -1 215-12
Control: tag -1 confirmed

Ça va Didier,

Didier Roche [2015-03-06  9:36 +0100]:
> In debian, tmp.mount is disabled through a distro-patch by default. It means
> we don't want user's system to get /tmp on tmpfs without explicit enablement
> (either by enabling tmp.mount unit or via fstab).
> 
> We noticed that starting an unit using "PrivateTmp=yes" will pull tmp.mount
> (which mounts /tmp on tmpfs) in its requirements chain (even if this unit is
> condition fail).

Confirmed. "systemctl start colord" or "systemd-timesyncd" will start
tmp.mount and thus overmount the existing /tmp in the running system.
I reproduced that in a clean sid VM (with LXDE, but I suppose that
doesn't matter much).

> We need to find a way to ensure that tmp.mount is never accidentally
> trigger, while still enabling the user using fstab to enable /tmp as tmpfs.
> Enabling the unit to get the same effect would be a nice addition.

I dislike masking it, as that will most probalby lead to problems with
units which have a Requires=tmp.mount (directly or indirectly), these
would block on a masked unit.

I think the best way forward is to either not ship the unit at all and
document in README.Debian to add /tmp as tmpfs in fstab [1], or ship
it in /usr/share/doc/systemd/ as an example, and document how to
enable it from there.

Michael, WDYT?

Thanks,

Martin

[1] I have "none /tmp tmpfs defaults 0 0" in fstab
-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)