Re: [RFC] Split up policycoreutils

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

> 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@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.



[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux