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

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>