* Re: [RFC] Split up policycoreutils
2016-10-31 18:05 ` Stephen Smalley
@ 2016-10-31 18:11 ` Dominick Grift
[not found] ` <eaeb9dc4-e69f-47de-50ad-083ce97e1153@gmail.com>
` (3 subsequent siblings)
4 siblings, 0 replies; 28+ messages in thread
From: Dominick Grift @ 2016-10-31 18:11 UTC (permalink / raw)
To: selinux
[-- Attachment #1.1: Type: text/plain, Size: 5047 bytes --]
On 10/31/2016 07: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?
>
> - 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.
semodule itself is also optional and not only with CIL but also with
monolitic policy.
maybe:
semodule (just semodule)
semodule-utils (all the other semodule related)
>
> _______________________________________________
> 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.
>
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 648 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
[parent not found: <eaeb9dc4-e69f-47de-50ad-083ce97e1153@gmail.com>]
* Re: [RFC] Split up policycoreutils
2016-10-31 18:05 ` Stephen Smalley
2016-10-31 18:11 ` Dominick Grift
[not found] ` <eaeb9dc4-e69f-47de-50ad-083ce97e1153@gmail.com>
@ 2016-10-31 18:42 ` Stephen Smalley
2016-11-01 19:00 ` Daniel J Walsh
2016-11-08 19:42 ` Stephen Smalley
4 siblings, 0 replies; 28+ messages in thread
From: Stephen Smalley @ 2016-10-31 18:42 UTC (permalink / raw)
To: SELinux
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.
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [RFC] Split up policycoreutils
2016-10-31 18:05 ` Stephen Smalley
` (2 preceding siblings ...)
2016-10-31 18:42 ` Stephen Smalley
@ 2016-11-01 19:00 ` Daniel J Walsh
2016-11-08 19:42 ` Stephen Smalley
4 siblings, 0 replies; 28+ messages in thread
From: Daniel J Walsh @ 2016-11-01 19:00 UTC (permalink / raw)
To: Stephen Smalley, SELinux
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.
We might want to copy each one to every package, but the python code
will need to be changed, and we will need to set up the translators to
include the new packages. Most of the po files are for the gui though.
> - 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?
Desktop files and pixmaps are just for the GUIs. sedbus.py is a dbus
interace for
sepolicy. I would think the dbus interfaces should stay with the low
level tools.
> - dbus/selinux_client.py (formerly
> policycoreutils/sepolicy/selinux_client.py) seems like leftover testing
> cruft. Remove?
This is just a test tool for testing out the dbus interface. Could be
renamed selinux_dbus_client
and not installed. Removing it would make it harder to test debug dbus
interfaces.
> - 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?
I think restorecond is still used by some people. But it is not needed
as much as it used
to be, because of file name transitions, and mv -Z type support.
> - 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?
Seems reasonable.
> - 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?
It is needed by the selinux-policy package. Used in post install to
limit the relabeling
of the system on file context changes. I would keep this in
policycoreutils.
> - 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.
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [RFC] Split up policycoreutils
2016-10-31 18:05 ` Stephen Smalley
` (3 preceding siblings ...)
2016-11-01 19:00 ` Daniel J Walsh
@ 2016-11-08 19:42 ` Stephen Smalley
2016-11-14 20:41 ` Jason Zaman
4 siblings, 1 reply; 28+ messages in thread
From: Stephen Smalley @ 2016-11-08 19:42 UTC (permalink / raw)
To: SELinux
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?
>
> - 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.
I've made further changes on the splitpolicycoreutils branch based on
the discussion (as well as rebasing it on latest master). This is a
call for final comments or objections before merging it to master. With
the current branch, we will have the following source tar files in a
release:
Unchanged:
* libsepol
* libselinux
* libsemanage
* checkpolicy
* secilc
Modified or new:
* policycoreutils (containing only hll, load_policy, newrole, run_init,
scripts/fixfiles, secon, semodule, sestatus, setfiles, setsebool)
* mcstrans
* restorecond
* semodule-utils (containing semodule_package, semodule_link,
semodule_expand, semodule_deps)
* selinux-dbus (containing org.selinux DBus configuration and python files)
- selinux-gui (containing system-config-selinux aka selinux polgengui)
- selinux-python (containing audit2allow, including its
sepolgen-ifgen-attr-helper helper program, chcat, semanage, sepolgen,
sepolicy)
- selinux-sandbox (containing sandbox)
No longer separate:
* sepolgen (moved inside of selinux-python)
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.
Feel free to suggest changes in structure, naming, or whatever.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [RFC] Split up policycoreutils
2016-11-08 19:42 ` Stephen Smalley
@ 2016-11-14 20:41 ` Jason Zaman
2016-11-15 14:47 ` Stephen Smalley
0 siblings, 1 reply; 28+ messages in thread
From: Jason Zaman @ 2016-11-14 20:41 UTC (permalink / raw)
To: Stephen Smalley; +Cc: SELinux
On Tue, Nov 08, 2016 at 02:42:31PM -0500, Stephen Smalley wrote:
> 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?
> >
> > - 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.
>
> I've made further changes on the splitpolicycoreutils branch based on
> the discussion (as well as rebasing it on latest master). This is a
> call for final comments or objections before merging it to master. With
> the current branch, we will have the following source tar files in a
> release:
>
> Unchanged:
> * libsepol
> * libselinux
> * libsemanage
> * checkpolicy
> * secilc
>
> Modified or new:
> * policycoreutils (containing only hll, load_policy, newrole, run_init,
> scripts/fixfiles, secon, semodule, sestatus, setfiles, setsebool)
> * mcstrans
> * restorecond
> * semodule-utils (containing semodule_package, semodule_link,
> semodule_expand, semodule_deps)
> * selinux-dbus (containing org.selinux DBus configuration and python files)
> - selinux-gui (containing system-config-selinux aka selinux polgengui)
> - selinux-python (containing audit2allow, including its
> sepolgen-ifgen-attr-helper helper program, chcat, semanage, sepolgen,
> sepolicy)
> - selinux-sandbox (containing sandbox)
>
> No longer separate:
> * sepolgen (moved inside of selinux-python)
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.
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?
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.
Also which of these are required to build refpolicy? the docs on that
may need updating later too.
4) mcstrans fails to build on my laptop, i'll send patches later. I
might have stricter warnings on or something.
5) in python/sepolicy/Makefile:
override CFLAGS += -I$(PREFIX)/include -DPACKAGE="policycoreutils"
should that be something instead of policycoreutils now?
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.
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.
-- Jason
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [RFC] Split up policycoreutils
2016-11-14 20:41 ` Jason Zaman
@ 2016-11-15 14:47 ` Stephen Smalley
2016-11-15 15:01 ` Stephen Smalley
2016-11-18 12:40 ` Daniel J Walsh
0 siblings, 2 replies; 28+ messages in thread
From: Stephen Smalley @ 2016-11-15 14:47 UTC (permalink / raw)
To: Jason Zaman; +Cc: SELinux, Daniel J Walsh
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [RFC] Split up policycoreutils
2016-11-15 14:47 ` Stephen Smalley
@ 2016-11-15 15:01 ` Stephen Smalley
2016-11-15 16:30 ` Jason Zaman
2016-11-18 12:40 ` Daniel J Walsh
1 sibling, 1 reply; 28+ messages in thread
From: Stephen Smalley @ 2016-11-15 15:01 UTC (permalink / raw)
To: Jason Zaman; +Cc: SELinux
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.
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [RFC] Split up policycoreutils
2016-11-15 15:01 ` Stephen Smalley
@ 2016-11-15 16:30 ` Jason Zaman
2016-11-16 19:00 ` Stephen Smalley
0 siblings, 1 reply; 28+ messages in thread
From: Jason Zaman @ 2016-11-15 16:30 UTC (permalink / raw)
To: Stephen Smalley; +Cc: SELinux
On Tue, Nov 15, 2016 at 10:01:12AM -0500, Stephen Smalley wrote:
> 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.
Okay this is roughly what I understood too so thats good. As things get
cleaned up more over time hopefully more gets ported to setools4 and
then we can start dropping the legacy parts. especially since the ones
before setools4 dont completely support policy format 30.
> >
> >> 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.
Aha! thanks, I was just looking at the output of ldd and didnt
investigate too far.
> >
> >> 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.
lets just keep it as-is, its hardly a big deal and there isnt anything
all that much better.
It all looks good to me currently. Cant think of anything else that
should be done before merging it in.
-- Jason
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [RFC] Split up policycoreutils
2016-11-15 16:30 ` Jason Zaman
@ 2016-11-16 19:00 ` Stephen Smalley
2016-11-16 19:07 ` Stephen Smalley
0 siblings, 1 reply; 28+ messages in thread
From: Stephen Smalley @ 2016-11-16 19:00 UTC (permalink / raw)
To: Jason Zaman; +Cc: SELinux
On 11/15/2016 11:30 AM, Jason Zaman wrote:
> On Tue, Nov 15, 2016 at 10:01:12AM -0500, Stephen Smalley wrote:
>> 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.
>
> Okay this is roughly what I understood too so thats good. As things get
> cleaned up more over time hopefully more gets ported to setools4 and
> then we can start dropping the legacy parts. especially since the ones
> before setools4 dont completely support policy format 30.
>>>
>>>> 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.
>
> Aha! thanks, I was just looking at the output of ldd and didnt
> investigate too far.
>>>
>>>> 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.
>
> lets just keep it as-is, its hardly a big deal and there isnt anything
> all that much better.
>
> It all looks good to me currently. Cant think of anything else that
> should be done before merging it in.
Ok, it is now merged to master, with the commit prior to the merge
tagged as "before_splitpolicycoreutils".
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [RFC] Split up policycoreutils
2016-11-16 19:00 ` Stephen Smalley
@ 2016-11-16 19:07 ` Stephen Smalley
0 siblings, 0 replies; 28+ messages in thread
From: Stephen Smalley @ 2016-11-16 19:07 UTC (permalink / raw)
To: Jason Zaman; +Cc: SELinux
On 11/16/2016 02:00 PM, Stephen Smalley wrote:
> On 11/15/2016 11:30 AM, Jason Zaman wrote:
>> On Tue, Nov 15, 2016 at 10:01:12AM -0500, Stephen Smalley wrote:
>>> 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.
>>
>> Okay this is roughly what I understood too so thats good. As things get
>> cleaned up more over time hopefully more gets ported to setools4 and
>> then we can start dropping the legacy parts. especially since the ones
>> before setools4 dont completely support policy format 30.
>>>>
>>>>> 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.
>>
>> Aha! thanks, I was just looking at the output of ldd and didnt
>> investigate too far.
>>>>
>>>>> 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.
>>
>> lets just keep it as-is, its hardly a big deal and there isnt anything
>> all that much better.
>>
>> It all looks good to me currently. Cant think of anything else that
>> should be done before merging it in.
>
> Ok, it is now merged to master, with the commit prior to the merge
> tagged as "before_splitpolicycoreutils".
And I dropped the ChangeLogs. Can revive and update them if there is
demand. Known unresolved issues:
- Need to split/update the policycoreutils/po files. Not sure if there
is an easy way to do that.
- I didn't fix the extraneous CFLAGS override in
python/sepolicy/Makefile; we can do that whenever.
- We'll need to decide how to handle VERSIONs going forward, e.g. if
we'll keep them in sync across components or let each one only track
changes to that component.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [RFC] Split up policycoreutils
2016-11-15 14:47 ` Stephen Smalley
2016-11-15 15:01 ` Stephen Smalley
@ 2016-11-18 12:40 ` Daniel J Walsh
1 sibling, 0 replies; 28+ messages in thread
From: Daniel J Walsh @ 2016-11-18 12:40 UTC (permalink / raw)
To: Stephen Smalley, Jason Zaman; +Cc: SELinux
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?
sepolicy is a big python library used to generate things like the man
pages and
all of the policy analyses tools. The goal was to change seinfo and
sesearch output
into something more easily consumed by non SELinux experts. sepolgen as
Stephen
said is just a link to sepolicy generate code which is used heavily for
generating policy
templates. sepolicy libraries are used by the sepolicy command suite.
> 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.
^ permalink raw reply [flat|nested] 28+ messages in thread