On Sat, Jul 09, 2016 at 05:52:52PM +0100, Richard W.M. Jones wrote: > On Fri, Jul 08, 2016 at 11:50:19AM -0400, Przemek Klosowski wrote: > > On 07/07/2016 04:59 PM, Richard W.M. Jones wrote: > > >On Wed, Jul 06, 2016 at 02:52:34PM +0000, Zbigniew Jędrzejewski-Szmek 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". > > On the other hand, what is their alternative solution? > > No solution was offered for the general user-initiated /.autorelabel > case. Some specific things were talked about for virt-builder but we > cannot use them for misc other reasons. Here's the upstream thread: > > https://marc.info/?t=146779851900007&r=1&w=2 OK, I get why people don't want to enter permissive mode automatically if /.autorelabel exists. Maybe as a compromise, libselinux could be taught to look at a separate runtime configuration file to check whether permissive mode should be enabled (e.g. /run/selinux/config)? Then at least it would be possible to start in permissive mode without having to modify /etc/selinux/config or muck around with providing a fake /proc/cmdline. Zbyszek -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
