Policy Module Packaging Guidelines (first draft)

[Paul Howarth]

Wart wrote:
> Paul Howarth wrote:
>> I've written up my thoughts on packaging policy modules with applications:
>>
>> http://fedoraproject.org/wiki/PackagingDrafts/SELinux/PolicyModules
>>
>> Fire away!
> 
> Looks good!
> 
> * s/scrope/scope/

Kindly fixed by Matthew yesterday.

> * In the 'separate subpackage' section do you want to add a note about
> making the -selinux subpackage an entirely new package with its own
> specfile, instead of a subpackage in an existing spec file?
> 
> Advantages:
> 
> Keeps the spec files much simpler and easier to read.
> Allows for separate maintainers of the main and -selinux packages.
> selinux packages can be updated without pushing new builds of the main
> package
> 
> Disadvantages:
> 
> Care must be taken to make sure that the selinux package is updated with
> the main package as needed.
> What value should be given for the URL and License tags in the spec file?

I think this idea merits some discussion. I tend of think of policy 
modules as being rather like kernel modules, in that they're things that 
are useful and usable whilst still under development but that ideally 
should eventually become unnecessary because they get merged into the 
main upstream project. So a separate package should be a short-lived 
package really.

I see the merits of having a separate package but I'd be in favour of 
such packages having to be justified as per kernel modules, along with a 
roadmap for an upstream merge.

> * I like the inclusion of the source files in %doc.  That can be
> extremely useful.
> 
> * You should note that you can't use 'service myapp condrestart' in
> %postun to transition a daemon process back to the unconfined domain
> after the module has been unloaded.  You have to first transition the
> daemon domain, then remove the policy module.  Otherwise the process
> will end up in an odd state and can't be killed until selinux is disabled:
> 
> %postun selinux
>     /usr/sbin/setsebool %{name}_disable_trans 1
>     /sbin/service %{name} condrestart > /dev/null 2>&1 || :
>     for selinuxvariant in %{selinux_variants} ; do
>         /usr/sbin/semodule -s ${selinuxvariant} -r mymodule &> /dev/null
> || :
>     done

Note added.

> * How should the selinux policy module be versioned?  Should it match
> the application versioning?  Are there any restrictions on policy module
> version numbers?

I don't think that policy numbers need bear any resemblance to the main 
package version; I've added a note to that effect. I'm not sure what the 
actual restrictions are on numbering, e.g whether any characters not in 
the class [0-9.] are allowed.

> * Using %{name} instead of 'myapp' in the templates would make it easier
> to copy/paste them into existing packages

I don't think "myapp" appears anywhere where it wouldn't be completely 
replaced in the template, so I don't think changing it to %{name} would 
be useful. However, the module name "mymodule" appears in a way that is 
very generic, so I added a define of %{modulename} at the top of the 
template and replaced "mymodule" with "%{modulename}" everywhere.

> * Don't you want to call 'fixfiles -R' in the %post and %postun sections
> of the sample templates?  You included it in the scriptlets section above.

I did, but I think the scriptlet code is likely to be so different for 
different packages that I didn't want to include too much in there on 
the basis that some people might just cut-and-paste things that aren't 
necessary.

How about I use "restorecon" in one of the templates and "fixfiles" in 
the other, in order to illustrate that there's no one "right" way of 
doing it?

Paul.