diff options
| author | Lennart Poettering <lennart@poettering.net> | 2018-01-05 12:20:22 +0100 |
|---|---|---|
| committer | Lennart Poettering <lennart@poettering.net> | 2018-01-11 15:12:16 +0100 |
| commit | db256aab13d8a89d583ecd2bacf0aca87c66effc (patch) | |
| tree | 0653543495bfdacba33ad303f1f4ff70bf301f15 /man/systemd.service.xml | |
| parent | notify: add new --uid= command (diff) | |
| download | systemd-db256aab13d8a89d583ecd2bacf0aca87c66effc.tar.xz systemd-db256aab13d8a89d583ecd2bacf0aca87c66effc.zip | |
core: be stricter when handling PID files and MAINPID sd_notify() messages
Let's be more restrictive when validating PID files and MAINPID=
messages: don't accept PIDs that make no sense, and if the configuration
source is not trusted, don't accept out-of-cgroup PIDs. A configuratin
source is considered trusted when the PID file is owned by root, or the
message was received from root.
This should lock things down a bit, in case service authors write out
PID files from unprivileged code or use NotifyAccess=all with
unprivileged code. Note that doing so was always problematic, just now
it's a bit less problematic.
When we open the PID file we'll now use the CHASE_SAFE chase_symlinks()
logic, to ensure that we won't follow an unpriviled-owned symlink to a
privileged-owned file thinking this was a valid privileged PID file,
even though it really isn't.
Fixes: #6632
Diffstat (limited to 'man/systemd.service.xml')
| -rw-r--r-- | man/systemd.service.xml | 18 |
1 files changed, 8 insertions, 10 deletions
diff --git a/man/systemd.service.xml b/man/systemd.service.xml index b98264c986..e796245ae5 100644 --- a/man/systemd.service.xml +++ b/man/systemd.service.xml @@ -264,16 +264,14 @@ <varlistentry> <term><varname>PIDFile=</varname></term> - <listitem><para>Takes an absolute filename pointing to the - PID file of this daemon. Use of this option is recommended for - services where <varname>Type=</varname> is set to - <option>forking</option>. systemd will read the PID of the - main process of the daemon after start-up of the service. - systemd will not write to the file configured here, although - it will remove the file after the service has shut down if it - still exists. - </para> - </listitem> + <listitem><para>Takes an absolute path referring to the PID file of the service. Usage of this option is + recommended for services where <varname>Type=</varname> is set to <option>forking</option>. The service manager + will read the PID of the main process of the service from this file after start-up of the service. The service + manager will not write to the file configured here, although it will remove the file after the service has shut + down if it still exists. The PID file does not need to be owned by a privileged user, but if it is owned by an + unprivileged user additional safety restrictions are enforced: the file may not be a symlink to a file owned by + a different user (neither directly nor indirectly), and the PID file must refer to a process already belonging + to the service.</para></listitem> </varlistentry> <varlistentry> |