11:15 a.m.
I've written up my thoughts on packaging policy modules with applications:
http://fedoraproject.org/wiki/PackagingDrafts/SELinux/PolicyModules
Fire away!
Paul.
12:18 p.m.
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/
* 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 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
* How should the selinux policy module be versioned? Should it match
the application versioning? Are there any restrictions on policy module
version numbers?
* Using %{name} instead of 'myapp' in the templates would make it easier
to copy/paste them into existing packages
* 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.
--Mike
12:26 p.m.
On Mon, Jul 31, 2006 at 10:18:42AM -0700, Wart wrote:
* s/scrope/scope/
It's a wiki, you know. :)
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
7:49 a.m.
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.
8:38 a.m.
On Tue, 2006-08-01 at 13:49 +0100, Paul Howarth wrote:
> * 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.
It can basically be any character; anything that works right with
strverscmp(). For sanity we probably want to stick to [0-9a-z.].
Upstream refpolicy versioning is x.y.z, where z is incremented every
time the module changes, y is incremented on a upstream release if the
module has changed since the last release (i.e. z != 0), and x is
incremented on major changes to the module.
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
6:08 a.m.
Christopher J. PeBenito wrote:
On Tue, 2006-08-01 at 13:49 +0100, Paul Howarth wrote:
>> * 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.
It can basically be any character; anything that works right with
strverscmp(). For sanity we probably want to stick to [0-9a-z.].
Upstream refpolicy versioning is x.y.z, where z is incremented every
time the module changes, y is incremented on a upstream release if the
module has changed since the last release (i.e. z != 0), and x is
incremented on major changes to the module.
Thanks; I've added these details to the wiki page.
Paul.
2:29 p.m.
Paul Howarth wrote:
Wart wrote:
> * 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.
Is there a concern that the main upstream project will start to get
bloated with the adoption of all of these individual policies? I had
thought of the policy modules as a way to separate the ongoing
maintenance of the policy file from the main upstream project. But as
you point out, if the policy module is only merged upstream once it has
stabilized, there shouldn't be much maintenance necessary. I guess I
can see both sides of the argument, and I don't have much of a
preference either way.
> * 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?
Sounds good to me.
--Mike
6:41 a.m.
Michael Thomas wrote:
Paul Howarth wrote:
> Wart wrote:
>> * 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.
Is there a concern that the main upstream project will start to get
bloated with the adoption of all of these individual policies? I had
thought of the policy modules as a way to separate the ongoing
maintenance of the policy file from the main upstream project. But as
you point out, if the policy module is only merged upstream once it has
stabilized, there shouldn't be much maintenance necessary. I guess I
can see both sides of the argument, and I don't have much of a
preference either way.
>> * 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?
Sounds good to me.
OK, changes now incorporated on the wiki page:
http://fedoraproject.org/wiki/PackagingDrafts/SELinux/PolicyModules
Paul.
6474
days inactive
6478
days old
selinux@lists.fedoraproject.org
7 comments
4 participants
participants (4)
-
Christopher J. PeBenito -
Matthew Miller -
Michael Thomas -
Paul Howarth