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) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
