Valdis.Kletnieks@xxxxxx wrote:
On Mon, 24 Jul 2006 10:41:34 EDT, Joshua Brindle said:
From: Daniel J Walsh [mailto:dwalsh@xxxxxxxxxx]
And in your install after the policy load
semanage port -a -t crossfire_port_t -p tcp MYPORTNUM
semanage port -a -t crossfire_port_t -p udp MYPORTNUM
This looks fine to me. If we start doing this the rpm spec file should
probably do it and should undo it on uninstall since the link will fail
if the module is removed without these rules being removed.
I'm an RPM idiot - will this still DTRT if another RPM package does
an 'Obsoletes:' on this one?
Yes. This package would get uninstalled, and the pre/post uninstall
scriptlet should remove the port definitions when the package is removed.
However, the big problem with using semanage in scriptlets is that
future versions of packages have to remember and be able to cope with
anything that had ever been added using semanage in any previous version
of the package. If file contexts or port numbers change over time, this
could be a major hassle. Being able to do it in a policy module would be
*much* better because the version numbering inherent in the modules
would take care of updating and removing old rules.
There would also be the problem of what do do when someone manually
added another port of type crossfire_port_t outside of rpm.
(ie. after all the 'port -a' and 'port -d',
we'll end up with one defined if needed?) and if the RPM is force-installed
a second time?
I have no sympathy for people force-installing things. In this case, I
don't think it would break anything though, so long as the uninstall
scriptlet was properly checking its parameters to ensure that it was an
uninstall and not a package update.
> (I've had more than one RPM that bombed in a post-install
scriptlet because of trying to useradd an existing userid, etc...)
That would be a packaging bug; great care should be taken to avoid
scriptlets returning non-zero exit codes and causing transaction failures.
Paul.
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
