1. Introduction
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.
We tested the code in this tutorial on Debian 11 (Bullseye) with GNU Bash 5.1.4. It should work in most POSIX-compliant environments.
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.
However, in addition to system services, systemd can also manage user services. The files for them are usually in a hidden directory, most often .config, under the $HOME of the owning user.
In fact, depending on the nature of the unit file, we might see different permissions.
3. systemd Unit File Permissions
Like any other filesystem object, unit files have specific permissions. For example, let’s use ls to check those of our earlier example system service unit file:
$ 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
[...]
Since the fully open (rwxrwxrwx) link permissions are irrelevant, let’s ensure we get the actual file permissions by using readlink and command substitution:
$ 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.
5. Summary
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.