[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: How best get rid of SELinux?

On Sat September 22 2007, Beartooth wrote:
> But I do not, alas!, recall reading any message there that meant
> anything to me. Since this is so, despite the fact that I've been running
> RH/F for nearly ten years, and spending a lot of time online for several
> before that, I concluded that I was likely not alone in my failure to
> spot straight up; so I posted about it, and the length of this thread
> appears to corroborate that.

Fair enough - I'm no programmer, but, I've found the messages useful from time 
to time. In one case, I got into a back and forth with one of the RH 
maintainers after filing a bug report based on one of those, and he had me do 
some things and got the issue straightened out in a subsequent policy update

>         I'm sure SELinux will *become* user-friendly, perhaps already in
> F8; the sooner the better.
agreed - it's getting better

>         It will come whenever there have been enough shocks of
> recognition of the form "You mean we have to explain *that*?! I thought
> puppies and little innocent children knew that."

I started the previous marathon thread on SELinux which occasioned some fairly 
nasty posts by some; that was the one about whether the NSA could have stuck 
a back door in. Despite some of the nasty responses by a few, I also found 
the discussion of interest. There's no harm in discussing. I concluded that I 
had no serious cause for concern and have kept SELinux turned on - I have yet 
to experience major disruptions from it; I have compared my setup to another 
machine on which I used to run BLAG  which is a Fedora derivative, and which 
turns SELinux off at boot time - BLAG seemed slightly faster to me on very 
similar hardware, enough to notice, but who's to say that was because of 
SELinux - the BLAG developer posited it was possible and that he'd gotten 
similar comments in the past, and that he really didn't do any other 
customizations that could account for increased performance. 

Claude Jones
Brunswick, MD, USA

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]