Re: [RFC] Split up policycoreutils

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

On 11/15/2016 09:47 AM, Stephen Smalley wrote:
> On 11/14/2016 03:41 PM, Jason Zaman wrote:
>> These look pretty good to me. I have written most of the ebuilds for
>> gentoo for these new packages but have not committed to the tree yet.
>>
>> There are a couple issues:
>> 1) What is the license for each of the tarballs? there is no license or
>> COPYING file in the dirs.
> 
> Fixed; I copied the policycoreutils/COPYING file into each of the new
> ones since they were all moved from policycoreutils.
> 
>>
>> 2) even tho i fixed up a lot of it so shouldnt be, I am *super* confused
>> about sepolicy vs sepolgen. there are like 4 separate dirs with those
>> names and the sepolicy Makefile makes a symlink for sepolgen. And then
>> there is the gui and the non-gui part of them. python/sepolicy/* should
>> hopefully die soon as things fully move over to setools4. should gui/ be
>> called system-config-selinux? also is it a redhatism or does it also
>> apply to other distros?
> 
> I also find this confusing; hopefully Dan (cc'd) can help clarify
> matters since he wrote most of this code.  I do know that the old
> sepolgen package (now python/sepolgen) was just a python module used as
> the backend for audit2allow and intended to become a more general policy
> analysis and generation backend, but never evolved that way, whereas
> gui/sepolgen was the old name for Dan's policy generation script/tool
> that is now just an alias for sepolicy generate. gui could be called
> system-config-selinux, but then it can also be invoked as sepolicy gui.
> It certainly started life as a Red Hat tool, but I'm not sure if anyone
> else is using it.  Refactoring all of it, including
> semanage/seobject.py, may make sense.
> 
>> 3) The deps of each of the bits is somewhat complicated to figure out.
>> semodule-utils looks like it only needs libsepol and libselinux and the
>> others look like they need most of the others? The makefile just builds
>> them in order but i'd like to specify more accurate deps in the gentoo
>> packages (especially external deps for each package) so they get
>> (re)built as required as things update.
> 
> I was also trying to make it easy to omit the optional components
> (OPT_SUBDIRS in the top-level Makefile), i.e. the ones that are not
> required for operation.  I would omit at least dbus, gui, mcstrans,
> restorecond, and sandbox by default from a base install.  python is
> likely needed for general purpose distros but could be omitted from
> embedded systems.  Actually, I don't see why semodule-utils components
> are linking with libselinux; they do not include selinux.h or make any
> calls to libselinux AFAICS, so I think that only truly depends on libsepol.

Fixed this too on the branch - removed the -lselinux from semodule-utils
Makefiles.
> 
>> Also which of these are required to build refpolicy? the docs on that
>> may need updating later too.
> 
> I would only expect libsepol, checkpolicy, and semodule-utils to be
> needed to build refpolicy, while libsemanage and policycoreutils would
> also be needed to install/load refpolicy.
> 
>> 4) mcstrans fails to build on my laptop, i'll send patches later. I
>> might have stricter warnings on or something.
> 
> Ok, I already had to fix a number of such warnings for it when I
> re-enabled building it by default on that branch (it was disabled
> before), so not surprised - just send the patches our way.
> 
>> 5) in python/sepolicy/Makefile:
>> override CFLAGS += -I$(PREFIX)/include -DPACKAGE="policycoreutils"
>> should that be something instead of policycoreutils now?
> 
> Probably can be removed entirely.
> 
>> 6) we have a policycoreutils-extra thats been floating around as part of
>> policycoreutils in gentoo. Mainly has rlpkg and selocal. After this
>> split is as good a time as any to cleanup and upstream them.
> 
> Ok, in that case we might want to think about what else if anything
> might go there.
> 
>> 7) I just noticed when looking through different Makefiles that some
>> variables default to different things. I'll send patches for this too
>> later once its merged in. Its nothing huge just better to be the same.
>>
>>> Note that the release script will add the selinux- prefix for dbus, gui,
>>> python, and sandbox when generating the source tarballs so that they
>>> have unique names suitable for source packages.
>>
>> This makes sense but I wonder if the name prefix is going to be annoying
>> when we end up needing to backport a patch on a release since the paths
>> would be different. But then again we've always had to edit them since
>> they are one level down so I dont think I mind this minor extra bit too.
> 
> Open to suggestions; I could add the prefix in the source tree itself;
> it just seemed ugly/unnecessary.  Or we could split up the repository
> into multiple ones / submodules, but I'm not keen on that.
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
>