On 10/31/2016 02:05 PM, Stephen Smalley wrote:
> 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?
Actually, I suspect this helper program could be rewritten in python to
use the setools4 interfaces these days.
>
> - 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.
