On Sat, 09.07.16 05:31, Peter Robinson (pbrobinson@xxxxxxxxx) wrote: > >> >>That patch is the answer to the (repeated) bug reports that relabelling > >> >>fails if enforcing=1 and the labels are sufficiently messed up. > >> >>Doing the relabel in permissive mode, without ever going to enforcing > >> >>mode, seems like the most reliable way out in this case. Starting in > >> >>enforcing mode first, and then switching back to permissive later > >> >>is a complication that increased chances of failure. > >> >Upstream SELinux have comprehensively rejected this approach. They do > >> >not want to have the presence of /.autorelabel cause SELinux to > >> >permissive mode. > >> I kind-of understand why they don't like it: "placing an invisible object in > >> a special location disables the security system". > > > > I must admit, I am not a fan of flag files in the root dir at all > > either I must say. In particular /forcefsck always has been my > > favourite bad idea of all... > > > >> On the other hand, what is their alternative solution? > > > > Well, it's systemd that loads the SELinux policy in the end, at the > > time we transition from the initrd to the host. We could add a generic > > flag file for bypassing this to /run. i.e. something like: if > > /run/systemd/bypass-selinux exists we will not load the selinux > > How does that work with /run being a tmpfs and losing state between > reboots? Hmm? The /run used in the initrd is the same that is used after the transition to the host. Flags created there in the initrd hence survive into the host system. Flag files in /run are not supposed to survive the reboot, that's why they are located in /run after all. It's just a nice way how to pass state from the initrd to the host, without any further lifetime. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
