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

[Didier Roche]

Package: systemd
Severity: serious

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).
For instance:
systemctl show -p Requires -p RequiresMountsFor systemd-timesyncd.service
Requires=-.mount tmp.mount
RequiresMountsFor=/var/lib/systemd/clock /tmp /var/tmp

Note that multiple units are using the private tmp feature like cups.

Also, if the unit is restarted (like an upgrade involving cups), /tmp 
will as well be remounted as tmpfs, which can wipe /tmp content to new 
process and get some annoying side-effects.


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/attachments/20150306/86527643/attachment.html>