On Thu, 2008-01-03 at 17:07 -0500, Daniel J Walsh wrote:
> Well there are several problems with allowing the individual maintainers
> manage their own policy.
>
> #1 they won't.
> #2 when they do, they do a very bad job of it. Or basically just end up
> with unconfined_t.
> #3 The tools are too slow. Having 100 semodule -i will cause the
> installation to take for ever.
> #4 Interaction between confined domains does not work well when multiple
> maintainers writing policy.
> sendmail, procmail, spamassassin, clamav, postfix, qmail, mailserver,
> pyzor ... All interact in very complex ways.
> #5 conflicts on file_context directories/files
See.. cause and effect.. #1 and #2 are the effects of #3 and the fact
that the policy is way too big and the whole system is way too
complicated.
Besides.. I have asked probably more than ten times (both electronically
and in person) about maintaining the selinux policy for hal in the
_upstream_ tarball but I've always been told that it's not possible or
I've been told to wait. In the meantime it's business as usual; things
are broken and people turn off SELinux.
Here's a challenge: Send me a patch against the hal git repo and the
RPM spec with the SELinux bits... Then I'll be happy to maintain it;
including spending time on learning SELinux well enough to do a good
job. Is this even possible? Should it be possible?
> David, You are writing an application that is trying to do things on
> behalf of the user as root. These activities will cause conflicts and
> need to be well controlled. So you are likely to run into problems with
> SELinux.
Sigh. Do you really honestly think this is a good answer for upstream
maintainers that are _willing_ to help?
David
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
