[refpolicy] [PATCH v2 8/8] Fix regexp for templated boolean generation

[refpolicy] [PATCH v2 8/8] Fix regexp for templated boolean generation

[Sven Vermeulen]

In the previous patch set, logic was added to ignore XML comments in a
template when generating the template or interface documentation, and
when that XML comment is not attributable to the template or interface
itself. This was accomplished by matching for a templated boolean or
tunable generation statement.

Sadly, the regular expression for it did not include the necessary
backtick and (forward) tick detection which is part of such statements:

  gen_tunable(`$1_something', false)
versus
  gen_tunable(domain_something, false)

In this patch, the regular expression is updated to support this
situation. This is both on the BOOLEAN match as well as
TEMPLATE_BOOLEAN. The reason this is needed on both matches is because
the TEMPLATE_BOOLEAN matches boolean calls with the $1, $2, ... in them
(to ignore) while the BOOLEAN match is also used for the in-line updated
template calls.

Without matching this on BOOLEAN level as well, the entire point of
supporting in-template boolean/tunable generation is lost as the
documentation for the generated booleans would be ignored.

Changes since v1:
- Also apply the regexp on BOOLEAN to allow generating templated
  boolean/tunable documentation

Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
---
 support/segenxml.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/support/segenxml.py b/support/segenxml.py
index 46a4a720..571b47f7 100644
--- a/support/segenxml.py
+++ b/support/segenxml.py
@@ -43,8 +43,8 @@ INTERFACE = re.compile(r"^\s*(interface|template)\(`(\w*)'")
 #	 -> ("bool", "secure_mode", "false")
 #	"gen_tunable(allow_kerberos, false)"
 #	 -> ("tunable", "allow_kerberos", "false")
-BOOLEAN = re.compile(r"^\s*gen_(tunable|bool)\(\s*(\w*)\s*,\s*(true|false)\s*\)")
-TEMPLATE_BOOLEAN = re.compile(r"^\s*gen_(tunable|bool)\(\s*([\w\$]*)\s*,\s*(true|false)\s*\)")
+BOOLEAN = re.compile(r"^\s*gen_(tunable|bool)\(\s*\`?\s*(\w*)\s*\'?\s*,\s*(true|false)\s*\)")
+TEMPLATE_BOOLEAN = re.compile(r"^\s*gen_(tunable|bool)\(\s*\`?\s*([\w\$]*)\s*\'?\s*,\s*(true|false)\s*\)")
 
 # Matches a XML comment in the policy, which is defined as any line starting
 #  with two # and at least one character of white space. Will give the single
-- 
2.13.6

[refpolicy] [PATCH v2 8/8] Fix regexp for templated boolean generation

[Chris PeBenito]

On 11/28/2017 12:33 PM, Sven Vermeulen via refpolicy wrote:
> In the previous patch set, logic was added to ignore XML comments in a
> template when generating the template or interface documentation, and
> when that XML comment is not attributable to the template or interface
> itself. This was accomplished by matching for a templated boolean or
> tunable generation statement.
> 
> Sadly, the regular expression for it did not include the necessary
> backtick and (forward) tick detection which is part of such statements:
> 
>    gen_tunable(`$1_something', false)
> versus
>    gen_tunable(domain_something, false)
> 
> In this patch, the regular expression is updated to support this
> situation. This is both on the BOOLEAN match as well as
> TEMPLATE_BOOLEAN. The reason this is needed on both matches is because
> the TEMPLATE_BOOLEAN matches boolean calls with the $1, $2, ... in them
> (to ignore) while the BOOLEAN match is also used for the in-line updated
> template calls.
> 
> Without matching this on BOOLEAN level as well, the entire point of
> supporting in-template boolean/tunable generation is lost as the
> documentation for the generated booleans would be ignored.

Unfortunately, I'm running into compile errors.  For a monolithic build 
I get:

/usr/bin/checkpolicy:  loading policy configuration from policy.conf
policy/modules/contrib/cron.te:714:ERROR 'syntax error' at token 'if' on 
line 521548:
	if (use_nfs_home_dirs) {
#line 714
checkpolicy:  error(s) encountered while parsing configuration




I added a commit to insert comments for else and closing brackets of 
tunable blocks, but I couldn't see what the problem was.

For a modular build I get:

/usr/bin/checkmodule:  loading policy configuration from tmp/cron.tmp
policy/modules/contrib/cron.te:712:ERROR 'syntax error' at token ':' on 
line 30749:
#line 712
		attribute user_home_content_type:
/usr/bin/checkmodule:  error(s) encountered while parsing configuration





> Changes since v1:
> - Also apply the regexp on BOOLEAN to allow generating templated
>    boolean/tunable documentation
> 
> Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
> ---
>   support/segenxml.py | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/support/segenxml.py b/support/segenxml.py
> index 46a4a720..571b47f7 100644
> --- a/support/segenxml.py
> +++ b/support/segenxml.py
> @@ -43,8 +43,8 @@ INTERFACE = re.compile(r"^\s*(interface|template)\(`(\w*)'")
>   #	 -> ("bool", "secure_mode", "false")
>   #	"gen_tunable(allow_kerberos, false)"
>   #	 -> ("tunable", "allow_kerberos", "false")
> -BOOLEAN = re.compile(r"^\s*gen_(tunable|bool)\(\s*(\w*)\s*,\s*(true|false)\s*\)")
> -TEMPLATE_BOOLEAN = re.compile(r"^\s*gen_(tunable|bool)\(\s*([\w\$]*)\s*,\s*(true|false)\s*\)")
> +BOOLEAN = re.compile(r"^\s*gen_(tunable|bool)\(\s*\`?\s*(\w*)\s*\'?\s*,\s*(true|false)\s*\)")
> +TEMPLATE_BOOLEAN = re.compile(r"^\s*gen_(tunable|bool)\(\s*\`?\s*([\w\$]*)\s*\'?\s*,\s*(true|false)\s*\)")
>   
>   # Matches a XML comment in the policy, which is defined as any line starting
>   #  with two # and at least one character of white space. Will give the single
> 


-- 
Chris PeBenito

[refpolicy] [PATCH v2 8/8] Fix regexp for templated boolean generation

[Sven Vermeulen]

On Wed, Nov 29, 2017 at 2:22 AM, Chris PeBenito via refpolicy
<refpolicy@oss.tresys.com> wrote:
> Unfortunately, I'm running into compile errors.  For a monolithic build
> I get:
>
> /usr/bin/checkpolicy:  loading policy configuration from policy.conf
> policy/modules/contrib/cron.te:714:ERROR 'syntax error' at token 'if' on
> line 521548:
>         if (use_nfs_home_dirs) {
> #line 714
> checkpolicy:  error(s) encountered while parsing configuration
>
>
>
>
> I added a commit to insert comments for else and closing brackets of
> tunable blocks, but I couldn't see what the problem was.

I now get the same issue with modular builds as well (the other build
error was due to a typo, my bad for not running sufficient testing,
I'm now doing the various builds beforehand), and would like to get
more deep into this before sending out v3 (which will also include a
fix for a case where not all arguments were processed correctly).

When you say "I added a commit to insert comments", do you mean inside
the policy/support/loadable_module.spt's tunable_policy declaration?

Is there perhaps a maximum depth of tunable_policy() chains that I
might be hitting?

Wkr,
  Sven Vermeulen

[refpolicy] [PATCH v2 8/8] Fix regexp for templated boolean generation

[Chris PeBenito]

On 12/02/2017 07:42 AM, Sven Vermeulen wrote:
> On Wed, Nov 29, 2017 at 2:22 AM, Chris PeBenito via refpolicy
> <refpolicy@oss.tresys.com> wrote:
>> Unfortunately, I'm running into compile errors.  For a monolithic build
>> I get:
>>
>> /usr/bin/checkpolicy:  loading policy configuration from policy.conf
>> policy/modules/contrib/cron.te:714:ERROR 'syntax error' at token 'if' on
>> line 521548:
>>          if (use_nfs_home_dirs) {
>> #line 714
>> checkpolicy:  error(s) encountered while parsing configuration
>>
>>
>>
>>
>> I added a commit to insert comments for else and closing brackets of
>> tunable blocks, but I couldn't see what the problem was.
> 
> I now get the same issue with modular builds as well (the other build
> error was due to a typo, my bad for not running sufficient testing,
> I'm now doing the various builds beforehand), and would like to get
> more deep into this before sending out v3 (which will also include a
> fix for a case where not all arguments were processed correctly).
> 
> When you say "I added a commit to insert comments", do you mean inside
> the policy/support/loadable_module.spt's tunable_policy declaration?

Yes.

> Is there perhaps a maximum depth of tunable_policy() chains that I
> might be hitting?

Since tunables are implemented as if blocks, they can't be nested.  So 
the max depth is 1.

-- 
Chris PeBenito