On Sat, 2014-01-25 at 21:51 +0100, Kevin Kofler wrote: > Dominick Grift wrote: > > No, that is a different discussion. > > Nonsense. That SELinux should be disabled is the whole point of this thread > (I know, I have started it!), all the suggestions (in the various > subthreads) of how to paper over the problem are off topic. > Sorry, I must have misinterpreted the subject: "Drawing lessons from fatal SELinux bug" > > Disabling SELinux does nothing to solve this. > > Oh sure it does. It eliminates this whole class of breakage (critical > components unable to do their job because SELinux gets in their way) once > and for all. This type of breakage keeps occurring, in fact one instance is > still ongoing in Rawhide while we're discussing this: > https://bugzilla.redhat.com/show_bug.cgi?id=1052317 > > Disable SELinux and nothing will keep those components (RPM, display > managers, etc.) from doing their work. > > > If anything, to me this is confirmation of why we need a good SELinux > > implementation. If this would happen to any other component then a good > > SELinux implementation could have contained the damage caused by issues > > just like this one. > > You don't seem to understand at all what SELinux is (it is not a tool > magically able to fix bugs, its only purpose is to keep programs from doing > their work)… I did not mean to suggest that. I meant to suggest that SELinux would be able to contain the damage, referring to "fatal" in: "Drawing lessons from fatal SELinux bug" > > The SELinux experience can, in my view be improved, and i believe your > > problem is not with SELinux itself but with how it is > > configured/implemented by default. > > … nor what it can or cannot do. (No amount of configuration can make SELinux > do anything other than block (i.e. break) things.) > Actually it is the other way around. SELinux blocks everything by default. Everything needs to be explicitly allowed by means of "configuration" > > I just believe that a little team coordination, and a little more care > > can go a long way, and that that is likely more efficient than trying to > > create tests that would catch all of the bugs which sounds like utopia > > to me. > > What "coordination"? For example coordinate who does what where and when. > > > I am not saying that the tests can't be improved or that they should not > > be improved. It's just that in this case a little bit more care and a > > double check by another involved party would probably have prevent this, > > and similar other issues, in my view. > > Sure, dropping autokarma could help (and should be done in any case, that > Bodhi "feature" never made any sense), but ultimately there's no way around > disabling SELinux. Enabling it by default in Fedora has always been a > mistake! > > Kevin Kofler > -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
