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

[Didier Roche]

Le 06/03/2015 16:04, Michael Biebl a écrit :
> Am 06.03.2015 um 10:10 schrieb 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).
> The odd thing though is, that PrivateTmp=yes does not trigger the start
> of tmp.mount during boot at least on all the test systems I have.
>
> Do we know, why that is? A Required=tmp.mount should always start the
> referenced unit, but it seemingly doesn't.

For reference, I dig a little bit into it and asked on the upstream ML: 
http://lists.freedesktop.org/archives/systemd-devel/2015-March/029072.html

Let's see if the bug we are seeing is really due to tmp.mount not being 
explicitly referenced anywhere.