Bug#931753: DefaultDependencies=no ignores PrivateTmp=yes, but honors its implied RequiresMountsFor=

2019-07-13 Thread Trent W. Buck
Michael Biebl wrote: > Am 10.07.19 um 07:12 schrieb Trent W. Buck: > > > "systemd-analyze security systemd-resolved" claims for that > > PrivateTmp= "does not apply", though it clearly does. > > I guess this is the essence of the bug report then and the bug report > should be retitled something l

Bug#931753: DefaultDependencies=no ignores PrivateTmp=yes, but honors its implied RequiresMountsFor=

2019-07-10 Thread Michael Biebl
Am 10.07.19 um 07:12 schrieb Trent W. Buck: > "systemd-analyze security systemd-resolved" claims for that > PrivateTmp= "does not apply", though it clearly does. I guess this is the essence of the bug report then and the bug report should be retitled something like this: systemd-analyze security

Bug#931753: DefaultDependencies=no ignores PrivateTmp=yes, but honors its implied RequiresMountsFor=

2019-07-09 Thread Trent W. Buck
Trent W. Buck wrote: > But I also noticed that "systemd-analyze security" says that PrivateTmp=yes > will be ignored: > > # SYSTEMD_PAGER='grep apply' systemd-analyze security procps.service > PrivateTmp= Service > runs in special boot pha

Bug#931753: DefaultDependencies=no ignores PrivateTmp=yes, but honors its implied RequiresMountsFor=

2019-07-09 Thread Trent W. Buck
Package: systemd Version: 241-5 Severity: minor After discovering "systemd-analyze security", I went around adding systemd-level confinement to units, e.g. remove modprobe privileges from all units that don't modprobe. I noticed that adding PrivateTmp=yes to keyboard-setup.service and systemd-u