The modern way to initialize a Linux system involves systemd. This initialization manager handles many startup tasks during boot. The systemd structure includes unit files for creating, configuring, and managing resources.
In this tutorial, we discuss systemd unit file permissions. First, we talk about the application of unit files. After that, we go over their organization and permissions.
2. systemd Unit File Usage
As with any other process that the initialization manager maintains, when creating or removing systemd services, we use unit files.
These unit files contain configuration options in key=value pairs within different  sections. For example, we have the rsyslogd system service file:
$ cat /etc/systemd/system/syslog.service [Unit] Description=System Logging Service Requires=syslog.socket Documentation=man:rsyslogd(8) Documentation=man:rsyslog.conf(5) Documentation=https://www.rsyslog.com/doc/ [Service] Type=notify ExecStart=/usr/sbin/rsyslogd -n -iNONE StandardOutput=null Restart=on-failure # Increase the default a bit in order to allow many simultaneous # files to be monitored, we might need a lot of fds. LimitNOFILE=16384 [Install] WantedBy=multi-user.target Alias=syslog.service
In this case, the unit file is syslog.service in the /etc/systemd/system directory.
In fact, depending on the nature of the unit file, we might see different permissions.
3. systemd Unit File Permissions
$ ls -l /etc/systemd/system/syslog.service lrwxrwxrwx 1 root root 35 Oct 10 2022 /etc/systemd/system/syslog.service -> /lib/systemd/system/rsyslog.service
With the [-l]ong listing format, we get the full metadata. However, from the first letter of the permission set and the last column of the output, we can also see that /etc/systemd/system/syslog.service is an absolute symbolic [l]ink to /lib/systemd/system/rsyslog.service.
In fact, that’s common for unit files under the /etc/systemd directory. Most are links to files in other paths:
$ ls -lR /etc/systemd/system /etc/systemd/system: [...] lrwxrwxrwx 1 root root 40 Jan 01 01:10 dbus-org.freedesktop.Avahi.service -> /lib/systemd/system/avahi-daemon.service lrwxrwxrwx 1 root root 45 Oct 10 2022 dbus-org.freedesktop.timesync1.service -> /lib/systemd/system/systemd-timesyncd.service lrwxrwxrwx 1 root root 31 Oct 10 2022 sshd.service -> /lib/systemd/system/ssh.service lrwxrwxrwx 1 root root 35 Oct 10 2022 syslog.service -> /lib/systemd/system/rsyslog.service [...]
$ ls -l $(readlink /etc/systemd/system/syslog.service) -rw-r--r-- 1 root root 666 May 05 2022 /lib/systemd/system/rsyslog.service
At this point, we see information about the real syslog unit file:
- owned by root
- read permissions for everyone
- write permissions only for the owner, root
- no execute permissions
On the last point, although options like ExecStart contain commands, unit files overall do not (need to) get executed. Further, any local user can read a unit file through DBus, so the second point makes sense. Due to the sensitive nature of the file contents as well as the privileges of the potential parser, the third point is also adequate, restricting writes.
4. Setting the Correct systemd Unit File Permissions
After thoroughly looking at unit files and their metadata, let’s understand how to configure it correctly.
In fact, we only need two commands to set the proper permissions over a unit file:
$ chown root:root /etc/systemd/system/example.service $ chmod 0644 /etc/systemd/system/example.service
Of course, this applies to user service unit files as well, but with a different owner:
$ chown user:user $HOME/.config/systemd/user/example.service $ chmod 0644 $HOME/.config/systemd/user/example.service
Importantly, incorrect permissions usually trigger a warning message.
In this article, we explored unit files and their permissions.
In conclusion, many unit files are actually links, but their actual permissions reflect the file function.