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

Trent W. Buck trentbuck at gmail.com
Wed Jul 10 04:47:07 BST 2019


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-udev-settle.service caused ordering cycles.
This is because

  1. they want to run BEFORE zfs-mount, but
  2. PrivateTmp=yes implies RequiresMountsFor=/tmp /var/tmp, so they ALSO want to run AFTER zfs-mount.

So OK, the obvious answer is "don't do that, then" - remove PrivateTmp=yes.
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 phase, option does not apply
      ProtectHome=                                                Service runs in special boot phase, option does not apply
      ProtectSystem=                                              Service runs in special boot phase, option does not apply
      RootDirectory=/RootImage=                                   Service runs in special boot phase, option does not apply
      RemoveIPC=                                                  Service runs as root, option does not apply

If systemd ignores PrivateTmp=yes when DefaultDependencies=no, then
systemd SHOULD ignore the implied RequiresMountsFor= (and knock-on Requires=var-tmp.mount) when DefaultDependencies=no.



I realize this is probably a huge pain to fix.
Probably the implicit options are added at read time, but the "ignore conflicting options" is done much later,
at which time it's impossible to know if Requires=var-tmp.mount was added explicitly or implicitly.

Possibly an easy mitigation is just to log a warning like:

    WARNING: procps.service has both DefaultDependencies=no and PrivateTmp=yes; this won't do what you want!

There are already similar warnings for similar dumb mistakes:

    systemd[1]: /etc/systemd/system/charybdis.service:7: Unknown lvalue 'StartExec' in section 'Service', ignoring
    systemd[1]: charybdis.service: Service has no ExecStart=, ExecStop=, or SuccessAction=. Refusing.



PS: DynamicUser=yes implies PrivateTmp=yes, so I think it should also be "does not apply" for "special boot phase".

PPS: I ran into this on a system with ZFS, but it should be
reproducible anywhere that has a dedicated /var/tmp mount in
/etc/fstab.



More information about the Pkg-systemd-maintainers mailing list