On Tue, 19.04.16 16:24, Samuel Rakitničan (samuel.rakitni...@gmail.com) wrote:
> Hello, > > I have a system that is an upgrade from Fedora 23 to Fedora 24 Alpha. > Occasionally I get messages about selinux blocking systemd-hostnamed from > mounton access on /home. I can trigger this issue by running command > hostnamectl. > > Is this supposed to happen? Is systemd-hostnamed supposed to do something > in /home directories and what might be the right fix for this? > > On the second side I have another Fedora 24 system that is new install > using this same /home partition, and there is no this issue there. > > Secondly, why is name of process trimmed, like (ostnamed), is this > intentional? When PID 1 starts a service binary it will first fork off a process, then adjust the process' parameters according to the service config and finally invoke execve() to execute the actual service process. In the time between the fork and the exec, we use PR_SET_NAME to change the process' name to what is going to be started, to make it easy to map this to the eventual service started. Note however, that there's a strict size limit on he "comm" name (i.e. the process name that my be set with PR_SET_NAME, i.e. the one "top" shows), which means we have to truncate. We chop off the beginning of the string, since usually the suffix is more interesting (otherwise, all of systemd's various services would appears as "(systemd-)" – which isn't particularly useful). We enclose the name in (), in order to clarify that this is the process that is going to become the specified process eventually, but isn't it yet. Or in other words: the alert you see is not caused by systemd-hostnamed itself, it's caused by systemd while is preparing to start systemd-hostnamed. The actual SELinux mount alert you see is because systemd-hostnamed actually uses ProtectedHome= (check with "systemctl cat systemd-hostnamed", the last line). That switch uses fs namespacing to lock hostnamed into a sandbox where /home is mounted read-only, because it really shouldn't access that, ever. See systemd.service(5) for details about that switch. Normally, the SELinux policy should simply allow this however, please file a bug against the SELinux policy in fedora. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
