Re: [PATCH] add selpolgen

[Karl MacMillan <kmacmillan@mentalrootkit.com>]

Stephen Smalley wrote:
> On Fri, 2007-01-19 at 11:23 -0500, Karl MacMillan wrote:
>> Stephen Smalley wrote:
>>> On Fri, 2007-01-19 at 08:49 -0500, Stephen Smalley wrote:
>>>> On Thu, 2007-01-18 at 14:53 -0500, Karl MacMillan wrote:
>>>>> Stephen Smalley wrote:
>>>> We can follow whatever practice is normal for python modules.  However,
>>>> how are those usually packaged?  Separate from the application that uses
>>>> them?  Or together?  As it stands, this module would become a dependency
>>>> of audit2allow and thus of policycoreutils; is there any benefit to
>>>> packaging it separately?
>>> Or conversely, we could remove audit2allow from policycoreutils and put
>>> it and this new python module into a single package.  It isn't as though
>>> audit2allow is fundamental to system operation anyway.
>>>
>> I think that the separation is desirable and matches current python 
>> practice. The sepolgen module is meant to be generic and available to 
>> many python programs (which is why it gets installed in python 
>> site-packages).
> 
> Ok.
> 
>> I would rather break policycoreutils into multiple packages to remove 
>> the dependency on this for minimal installations. There is a natural 
>> division between system / policy management tools (e.g., restorecon, 
>> semanage, newrole) and policy debugging / development (audit2allow, 
>> audit2why, semodule_link, semodule_expand, and semodule_package).
>>
>> Maybe selcoreutils (which can eventually be bundled under a single 'sel' 
>> command like git / svn) and policydevtools. Distros may want to further 
>> divide those packages into graphical and non-graphical.
> 
> Are you proposing a new upstream structure, or just how the existing
> policycoreutils might be split into multiple packages by distributions?
> Fedora already splits newrole and system-config-selinux into their own
> distinct sub-packages (policycoreutils-newrole, policycoreutils-gui),
> the former to avoid a need for newrole under targeted policy due to
> concerns about its suidness.
> 

New upstream structure - though just letting distros split them how they 
will is also fine with me.

> I'd tend to put semodule_package into the same class as
> checkmodule/checkpolicy (policy build toolchain, required even to build
> local modules, and thus needed by ordinary users), whereas
> semodule_link, semodule_expand, and semodule_deps are more
> development/debug tools oriented toward selinux developers.  audit2allow
> and audit2why are likewise user-oriented tools rather than only being
> used by selinux developers.
> 

Agreed.

> libsemanage invokes setfiles, genhomedircon, and load_policy, so it
> requires them.  There is presently a circular dependency between
> libsemanage and genhomedircon.
> 

genhomedircon should probably be folded into libsemanage eventually.

Karl

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.