From: domg472@gmail.com (Dominick Grift)
Date: Tue, 18 Jan 2011 17:27:00 +0100
Subject: [refpolicy] optional_policy blocks
In-Reply-To: <1295367365.3083.27.camel@tesla.lan>
References: <1295361554.3083.8.camel@tesla.lan> <4D35AA8C.5050001@gmail.com>
	<1295367365.3083.27.camel@tesla.lan>
Message-ID: <4D35BF54.7090003@gmail.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/18/2011 05:16 PM, Guido Trentalancia wrote:
> Hello again !
> 
> On Tue, 18/01/2011 at 15.58 +0100, Dominick Grift wrote:
>> On 01/18/2011 03:39 PM, Guido Trentalancia wrote:
>>> Hello !
>>>
>>> I am trying to build and test a modified version of the git reference
>>> policy. It is being built of type MCS and not monolithic.
>>>
>>> Unfortunately, it seems that for some reason all of the
>>> "optional_policy" blocks that are often used in TE files are not being
>>> compiled in.
>>
>> Because optional policy does not apply to monolithic policy. All modules
>> are in a single module (the base module), thus all dependencies are
>> installed.
>>
>> optional policy is used for modular policy where many modules reside in
>> their own policy module. This enabled you to add and remove specific
>> modules and introduces the issue of dependencies.
>>
>> the optional policy (policy in optional policy blocks) say's if this
>> policy is available then use it and if its not available then ignore it.
> 
> This is my understanding. optional_policy() is a macro. Such macro
> allows to optionally call one or more interfaces depending on whether a
> module is included in the policy.
> 
> The optional_policy() support macro implements this capability
> differently depending on whether a monolithic policy, base module, or
> loadable module is being built.
> 
> However, the concept from a policy writer's perspective is the same. If
> the module is being included in the build process, then the interfaces
> defined within the optional_policy block are also called.
> 
> I believe that for modular policies it expands to an "optional" block,
> while for monolithic policies it expands to an "ifdef" block, see for
> example:
> 
> http://selinuxproject.org/page/NB_RefPolicy#optional_policy_Macro
> 
> http://www.nsa.gov/research/selinux/list-archive/0601/thread_body117.shtml
> 
> In any case, from the point of view of this discussion it doesn't really
> matter whether the policy being built is monolithic or modular. The
> point is that apparently the macro does not get expanded and built. I am
> doing: make install-src ; make conf ; make policy ; make install ; make
> load as described in the INSTALL file for the reference policy. And
> again, as already mentioned, the relative modules appears to be built
> and loaded (they appear in policy/modules.conf and also in the output of
> semodule -l).
> 
> What am I missing then ?
> 
>> Sounds strange indeed. Are you sure it is not including any of the
>> policy in optional policy block or just some?
>>
>> If it is just incidental then it could be an error in the interface in
>> the optional policy block.
>>
>> If this really applies to all optional policy then i guess something
>> else is going on.
> 
> Very strange. I have not checked every optional block in the policy. For
> sure, it is not including those that I have created.
> 
> If there was an error in the interface definition, then the compiler
> would complain !

No not always. That is why i mention it.

For example if you require a type that does not exist in a interface,
Then it will build but the optional policy will not be included.

> It might well be the case that none of the optional_policy() blocks got
> compiled in....
> 
> Regards,
> 
> Guido
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk01v1QACgkQMlxVo39jgT9VBgCfW5kYzuX7gquhMkl+Si9bogWv
Kw8An0A9KLpMPtYFsmVk0af4yXptlezz
=5oXR
-----END PGP SIGNATURE-----