On 10/24/2016 11:15 PM, Daniel J Walsh wrote: > > > On 10/24/2016 09:21 AM, Stephen Smalley wrote: >> On 10/24/2016 09:13 AM, Stephen Smalley wrote: >>> On 10/22/2016 09:44 AM, Chris PeBenito wrote: >>>> On 10/21/16 13:47, Stephen Smalley wrote: >>>>> 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). >>>> I'm not sure where the main part of sepolicy should go, but it would be >>>> nice to split it out since it depends on setools which has heavier >>>> dependencies than a core system package should typically have IMO >>>> (NetworkX, which pulls in scipy, numpy, matplotlib, etc.) >>> I would be in favor of that too, but hesitated to do so because it would >>> require moving audit2allow and semanage out of policycoreutils as well. >>> Fedora does package those as part of policycoreutils-python (along with >>> sepolgen). Arguably audit2allow isn't necessary for production (but >>> many users of SELinux in Linux distributions rely on it), but semanage >>> is more fundamental these days. >>> >>> However, if people are open to moving sepolicy, audit2allow, and >>> semanage, possibly combining them with sepolgen in a new >>> subdirectory/package, then we could explore that. >> We'd also need to move chcat, since it imports seobject. However, on >> that topic, is there any reason to retain chcat? It was created for the >> original discretionary MCS model and I'm not sure it is used anymore by >> anyone. >> >> >> _______________________________________________ >> 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. >> >> > I would suggest we remove it. I would not mind terribly removing it either but I prefer that we first see if we can fit this in somewhere else. I do not see this as a core utility but if someone wants to implement the old MCS model then one should be able to do so. > _______________________________________________ > 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. > -- 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:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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.
