[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Draft spec for new dpkg "triggers" feature

On Wednesday 31 January 2007 04:08, Ian Jackson <iwj@ubuntu.com> wrote:
> We currently envisage three kinds of triggers:
>  * Explicit triggers.  These can be activated by any program
>    by running dpkg-trigger (at any time, but ideally from a maintainer
>    script).
>  * File triggers.  These are activated automatically by dpkg
>    when a matching file is installed, upgraded or removed as part
>    of a package.  They may also be explicitly activated by running
>    dpkg-trigger.
>  * Special triggers, which activate magic code in dpkg itself.
>    Currently none of these are defined.

Manoj's recent work on SE Linux policy has the package examine the system to 
determine which packages are installed and to then load the matching SE Linux 
policy modules.  This works OK on an initial install as a complete relabel is 
performed after installing the policy.

But for a running SE Linux system when a new package is installed we need the 
policy loaded first.

For example if a SE Linux system does not have Apache installed then the 
Apache policy will not be loaded (saves some kernel memory).  If you install 
one of the Apache packages then ideally the SE Linux policy module will be 
loaded first (before the package is unpackaged).

This means that we need a trigger for new package selection and the trigger 
has to be completed before any of the packages are installed.

In the case of SE Linux it's not really a problem if the installation of the 
package in question is never performed.  For example if I ask Apt to install 
Apache and then press ^C after the SE Linux trigger has been called to load 
the policy but before the Apache package is unpacked then it's OK.  There 
will be slightly more kernel memory in use but the system operates as before.  
If I never decide to install Apache then the policy just keeps running, I 
easily can remove it if necessary.

Inserting and removing SE Linux policy modules if similar to running modprobe 
and rmmod except that the state is changed on disk and applies after the next 

http://etbe.blogspot.com/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

Reply to: