- The sepolicy plugin needs them so the symbols can't be hidden, but
these are not something external API-users should be messing with.
- Ultimately we'll want to push the actual labeling from FSM to
the plugin, insulating rpm from all SELinux specifics, this is
just a band-aid temporary "solution" to keep this out of the API.
- Plugins are by their very nature arch specific, while /usr/lib/rpm
is a hodgepodge of all sorts of ... stuff, most of which is
arch-independent and all. Use %{_libdir}/rpm-plugins to cleanly
differentiate 32 vs 64bit plugin paths
This adds a new plugin specifically for a collection to load SELinux
policy. This implements the post_add and pre_remove plugin hooks. The
only time anything happens during the pre_remove hook is if post_add was
not called (i.e. if the transaction only removes policies).
This plugin extracts all the policy information from packages in the
sepolicy collection during the open te hook. It then determines which
policies should be installed/removed based on if the package is being
installed/removed and the type of the policy and the system policy. It
then executes semodule (or uses libsemanage if semodule cannot be
executed or installing in a chroot) to remove and install the necessary
policies. It then reloads the selinux state, reloads the file contexts,
and if necessary, relabels the file system.
This moves most of the plugin logic to a new rpmplugins file with a
struct and functions for managing plugins, allowing for plugins to carry
state. This also adds init and cleanup hooks for plugins to initialize
and cleanup their state, and a new 'open te' hook allowing plugins to
read and save information from transaction elements.
This also generalizes the plugin architecture a bit so it isn't so
specific to collections.
- the exec plugin was using a private copy of rpmchroot.c to avoid
RPM_GNUC_INTERNAL on the API, better let the plugins use librpm
state instead
- the chroot API really belongs to librpmio but for now...
This patch adds a generic plugin, exec.so, that should be sufficient for the
majority of Collection actions. After all packages in a Collection have been
installed/removed, this plugin executes the arguments by calling system(3),
allowing for a very generic and powerful method to perform many actions.
This also adds two sample macros as examples of the format, using the exec.so
plugin.
Panu Matilainen