gary.buhrmaster at gmail
Apr 23, 2012, 7:41 PM
Post #2 of 3
> 1. Are they a good idea for mythweb functionality or performance?
The *may* be needed if you are running selinux in various
enforcing modes, and depending on your policies.
> 2. Are there security implications where I wouldn't want to set this
This is as much philosophical as strictly technical.
If *I* am running selinux, I do not want packages to
change my httpd selinux settings silently or without
my permission. I have absolutely no problem if I am
asked, but if I want my system secure, I want it
to stay secure until *I* explicitly approve of a
I believe that such requirements (as in configuring
httpd itself) should be documented in the README(s),
and for those that do not RTFM, well, so be it.
The bugzilla entry does indicate that this should
be in the README, so I would agree with that
recommendation (and no to automatic mangling).
There are certainly others that think that systems
should simply change security configurations as
needed (they are also the group more likely to run
MythTV as root.)
OT question: how many people are running MythTV
with selinux in full enforcing mode (rather than
permissive or disabled)? I remember trying to run
my combined BE/FE in enforcing mode many many
many many years ago (and many many many
configuration changes ago), and things did not go
well (it was due to my choice of partitioning, and
the evil use of twisty symlinks, all different). Is
enforcing mode now considered best practice?
> The selinux settings in question:
> setsebool httpd_builtin_scripting on
This already defaults to on for "targeted" mode
and should not be needed unless someone
has explicitly turned it off, but reminding them
is not badness.
> setsebool httpd_can_network_connect on
> setsebool httpd_can_network_connect_db on
These default to off, and for full functionality
would need to be set to on for at least *some*
configurations (I am not sure if "localhost"
counts as a network/db connection, but even
so, in the general case, you may need them).
mythtv-dev mailing list
mythtv-dev [at] mythtv