Split policycoreutils up?

[Stephen Smalley <sds@tycho.nsa.gov>]

Hi,

policycoreutils started life as a minimalist set of utilities required
for SELinux operation.  It has grown far beyond that, and now includes a
number of non-essential components.  Some of those components have also
grown dependencies on external libraries from setools (in particular,
sepolicy, which is now a dependency for semanage, sandbox, and gui?).

So I was wondering whether it is worthwhile to split up policycoreutils
into multiple source packages, or otherwise support a minimalist build
of it.

Fedora already generates multiple separate binary packages from it:

1) policycoreutils (secon, semodule_*, fixfiles, genhomedircon,
load_policy, restorecon, run_init, semodule, sestatus, setfiles, setsebool)

Not sure what relies upon secon that leads to it being included in the
base package - maybe init scripts? semodule_deps, semodule_expand, and
semodule_link are all purely developer tools that shouldn't be needed in
common practice.  semodule_package is necessary only if building policy
modules, so I'd tend to put that in a -devel package.  Not sure whether
run_init is truly required in Fedora outside of -mls policy?  sestatus
isn't required for operation but is convenient to have.  The rest make
sense to me as part of the base package.

2) policycoreutils-devel (sepolicy and sepolgen* from the separate
sepolgen source package, which gets combined into the policycoreutils
source package in Fedora)

Not sure how much sense this one makes in its current form separate from
policycoreutils-python below.

3)  policycoreutils-python (audit2allow, audit2why, seamanage, chcat,
sandbox?, /usr/lib*/python*/site-packages/*)

Confused by why sandbox appears here but its dependencies are below in
policycoreutils-sandbox.  audit2allow/audit2why are effectively policy
development tools.   chcat seems more like a base utility although I'm
not sure how many people use it rather than just using chcon -l or
semanage these days.  semanage is required for management if using
managed/modular policy, so it is more fundamental than
audit2allow/audit2why, chcat, or sandbox.

4) policycoreutils-gui (selinux-polgengui, system-config-selinux)

Seems reasonable.

5) policycoreutils-newrole (newrole)

I'd tend to put this into the base or at least with run_init.  IIRC, it
was only separated to avoid having an unnecessary setuid/file-caps
binary in the non-MLS case. If the common thread is MLS, then I'd tend
to put newrole, run_init, and chcat together.

6) policycoreutils-restorecond (restorecond)

Makes sense as an optional component.

7) policycoreutils-sandbox (seunshare, /usr/share/sandbox)

Ditto, except that I'd expect sandbox from policycoreutils-python in
this one too.

So, I guess the question is whether it provides any value to split up
the source package itself (as opposed to just the generated packages),
and if so, what the best decomposition is.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.