On 9/7/2014 11:24 PM, Tom Lane wrote:
> Hm ... would that not be in direct conflict with existing policy
> variables?
good questions, and I'm not versed enough in the specifics to be able to
answer. indeed, I have a rather shaky and sketchy understanding of the
details of selinux... in my development lab environment, too often
the first problem its caused, I've had to shut it off so my developers
could get their jobs done. our software is only used inhouse, and
manufacturing operations has not been remotely interested in dealing
with selinux. Even if I carefully supported it with my group's stuff,
they'd still be shutting it off for other reasons, beyond my control.
> I don't actually know a lot about what the standard Red Hat selinux
> policy does in this area. If it were seriously broken, I'd probably
> have heard more about it during the years I worked there. Not that
> that's much of an argument, but it's some evidence for "there's no
> fire here, only smoke". Anyway, I remain of the opinion that it'd
> be best to press Red Hat's selinux people to fix/clarify/document
> their policy's behavior for apache-to-database connections. Trying
> to override the system policy with drive-by updates seems like a recipe
> for disaster.
presumably other add-on packages need specific policies for themselves
to operate in a selinux environment? I wonder how they do this. I'm
envisioning this policy we add as something that doesn't conflict with
existing policies, just adds the minimal magic to make it play nicely.
--
john r pierce 37N 122W
somewhere on the middle of the left coast