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

Didier Roche didrocks at ubuntu.com
Fri Mar 20 08:06:49 GMT 2015


Le 20/03/2015 09:03, Michael Biebl a écrit :
> [adding the bug to CC]
> Am 20.03.2015 um 08:46 schrieb Didier Roche:
>> Le 20/03/2015 08:39, Michael Biebl a écrit :
>>> thanks for the patch. I had something like this in mind.
>>> We could be extra nice and only add the After=tmp.mount if tmp.mount is
>>> actually enabled, because we only need the After ordering in this case.
>>> But that's mostly a cosmetic issue and I'm happy to ship the patch as is.
>> That's a nice idea. It needs testing though to ensure that the fstab
>> generator generated the right enablement for that unit (in case the
>> tmpfs config was done in fstab).
> /etc/fstab entries are automatically hooked up in
> /run/systemd/generator/local-fs.target.requires/ unless the fstab entry
> uses noauto.
>
> That said, I'm not sure if we should really test the file system path.
> We should check if systemd offers an API for this.
>
> Also, we need to ensure that any later
>> enablement of that unit, this is taken into account by new units. Not
>> sure I'll have time to test this properly today, will be more early next
>> week if needed though.
> As said, I'd probably be happy to ship the patch as is and would include
> it in the upload I plan this weekend.
>
> We can defer this to a later upload though, if you want?
>
Sounds the best approach: ship it as it is for this week-end upload, at 
least the immediate concern is addressed this way.
I'm keeping in mind to check if we can request for the unit enablement 
for a later upload.

(Note: the patch is against experimental, I can rebase on master and 
include the bug reference if you wish, but I guess you are going to 
merge other fixes as well…)

Thanks for the bug triaging work btw :)
Cheers,
Didier




More information about the Pkg-systemd-maintainers mailing list