On 10/21/2016 01:47 PM, Stephen Smalley wrote:
> Hi,
>
> policycoreutils started life as a small set of utilities that were
> necessary or at least widely used in production on a SELinux system.
> Over time though it has grown to include many optional components, and
> even within a given subdirectory (e.g. sepolicy) there seem to be a
> number of components that should be optional (e.g. the dbus service).
> I'd like to propose that we move a number of components out of
> policycoreutils into their own top-level subdirectory (possibly grouping
> some of the related ones together).
>
> Some possible components to move and the rationale for doing so include:
>
> - gui: not required for operation. Unsure if this is even used outside
> of Fedora, or how widely it is used within Fedora compared to the
> command line tools. Packaged separately by Fedora as part of
> policycoreutils-gui.
>
> - mcstrans: not required for operation outside of MLS environments (and
> even there, only if using that label encoding functionality), not built
> by default even upstream (omitted from policycoreutils/Makefile).
> Packaged separately in Fedora as mcstrans.
>
> - restorecond: not required for operation, adds dbus and glib
> dependencies, largely obsoleted by name-based type transition support in
> the kernel. Packaged separately in Fedora as policycoreutils-restorecond.
>
> - sandbox: not required for basic operation of SELinux. Packaged
> separately by Fedora as policycoreutils-sandbox.
> restorecond
> - semodule_deps/expand/link: developer tools only, not required for
> operation, unlike semodule. Packaged separately by Fedora as part of
> policycoreutils-devel.
>
> - sepolicy/{org.selinux*,selinux_client.py,selinux_server.py}: D-BUS
> service for managing SELinux, not required for basic operation, not
> desirable in high security environments. Packaged separately by Fedora
> as part of policycoreutils-gui. Could perhaps be combined with the gui
> above, although I think they are logically distinct.
>
> We could of course go further, but those seem to be the most obvious
> candidates.
>
> Thoughts?
For discussion purposes, I've pushed a splitpolicycoreutils branch that
moves the above components and others identified in the discussion
thread, and makes it easy to omit the non-core components from the
build. Take a look and see what you think. Known issues:
- I did not deal with splitting the policycoreutils/po files and moving
them around. Not sure what the best way to handle that is.
- python/sepolicy likely needs further rearrangement. I am unclear on
the purpose/use of the desktop file and pixmaps; if those are only for
the gui, then they can be moved to gui/, but I don't understand why they
are called sepolicy* or located here. Also, should
python/sepolicy/sepolicy/sedbus.py be moved over to dbus/ or stay here?
Dan?
- dbus/selinux_client.py (formerly
policycoreutils/sepolicy/selinux_client.py) seems like leftover testing
cruft. Remove?
- restorecond presently reuses source code directly from setfiles, so
building it as a separate package may be a nuisance. OTOH, I'm not
entirely clear on whether restorecond needs to be kept around at all
anymore?
- policycoreutils/sepolgen-ifgen contains a single C program,
sepolgen-ifgen-attr-helper, that is only used by
python/audit2allow/sepolgen-ifgen. Any reason to not just coalesce it
into python/audit2allow even though it is not python itself?
- After the restructuring, the only script left in policycoreutils is
fixfiles. Technically, that's not required for production either as one
can always just run setfiles or restorecon directly, but distros seem to
rely on it. Is it worth moving just to free policycoreutils of any bash
dependencies, and if so, where?
- I moved policycoreutils/semodule_{deps,expand,link} into a new
semodule-utils directory. This might however be slightly confusing
since semodule and semodule_package remain in policycoreutils since they
are required and not merely for developers. Feel free to suggest
another name or structure. Actually, I guess semodule_package might be
optional now with CIL, so perhaps that one can be moved too.
_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
