So I'm diving into the intricacies of systemd and it's ability to meter resources with cgroups like cpu, io, and memory.

Is there also a way to control the directories a process has access to with systemd? For instance, /usr/bin is generally marked o+rX, and I'd like a webserver process to be locked out of that directory. There have been quite a few software exploits where you can read arbitrary files from disk, this would enhance a layered approach to security.

I'm sure this could be done with some really fancy filesystem permissions, but was wondering if there was a better way. Thank server fault!


You have a number of options actually, which you can define in the unit file(s) for your services. They all work on the same principle, by using bind mounts within the namespace systemd sets up for the service. Certain parts of the file-system are either mounted read-only, or rendered completely invisible/inaccessible by mounting an empty directory.

PrivateTmp is arguably the most common.
Enabling PrivateTmp sets up a new file system namespace for the executed processes and mounts private /tmp and /var/tmp directories inside it that is not shared by processes outside of the namespace.

If true, mounts the /usr and /boot directories read-only for processes invoked by this unit.
If set to full, the /etc directory is mounted read-only, too. If set to "strict" the entire file system hierarchy is mounted read-only, except for the API file system subtrees /dev, /proc and /sys

Takes a boolean argument or "read-only". If true, the directories /home, /root and /run/user are made inaccessible and empty for processes invoked by this unit. If set to "read-only", the three directories are made read-only instead

If true, kernel variables accessible through /proc/sys, /sys, /proc/sysrq-trigger, /proc/latency_stats, /proc/acpi, /proc/timer_stats, /proc/fs and /proc/irq will be made read-only.

Paths listed in ReadOnlyPaths= are accessible for reading only, writing will be refused even if the usual file access controls would permit this.

Paths listed in InaccessiblePaths= will be made inaccessible for processes inside the namespace (along with everything below them in the file system hierarchy).

There might be more options though.

A more layered access policy would probably require SELinux, and a very thorough understanding of it as well as you probably need to adept the Multi Level Security policies.

  • How does systemd enforce these restrictions? Via integration with SELinux and/or lxc or ??? Also, are these features in common distros that use systemd (e.g., RHEL7), or are they relatively new in systemd?
    – Dan Pritts
    Apr 28 '17 at 14:50
  • @DanPritts check man systemd.exec for what your version supports.
    – HBruijn
    Apr 28 '17 at 14:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.