On 12/8/2010 9:13 AM, Christopher Chan wrote:
On Wednesday, December 08, 2010 09:31 PM, Les Mikesell wrote:
On 12/8/10 4:22 AM, David Sommerseth wrote:
On 30/11/10 03:52, cpolish@surewest.net wrote:
Christopher Chan wrote:
Les Mikesell wrote:
[...snip...]
As was already mentioned in another post, run in permissive mode, for a few days if you must, and go through all the things the software does and voila! setroubleshoot and/or logs tell you what needs doing.
Very optimistic, that. In my shop, some things run annually. A comprehensive system test = production, for a year. Just this morning a 1099 (annual tax-form) script failed in test.
So you would rather disable SELinux completely - 365 days a year, rather than to switch to permissive mode when running this script once a year?
I'm sorry, but I'm not able follow that logic.
In our case if something fails once a year we lose customers and money. I'd expect that to be fairly common.
Again, that particular process is unlikely to be missed and also show to be easily mitigated by doing a realtime switch from enforcing to permissive. Such annual processes are fairly common and usually run manually. You have yet to make a compelling case for completely disabling SELinux just for this sort of thing. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
loosing customers and money on an annual basis is a great reason to kill it. Make it able to work without updates interfering with a formerly running configuration on a regular basis and more folks will adopt it. Saying killing it because it is hurting your business isn't a valid reason is arrogant and frankly stupid. Frankly, there's several other distros that don't run SeLinux and they aren't anymore problematic when properly configured than RHEL is..and they just work. Let's put the SeLinux religion aside..make it not only technically superior but actually usable and helpful and you'll see a wider adoption. The kind of arrogance I've seen in this thread is a primary reason it won't get appreciable traction outside of RHEL and why it won't be a major tool in admins toolbox inside RHEL unless folks don't NEED the flexibility Linux in general offers and SELinux restricts.