2017-11-28 17:33:02

by sven.vermeulen

[permalink] [raw]
Subject: [refpolicy] [PATCH v2 8/8] Fix regexp for templated boolean generation

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 <[email protected]>
---
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


2017-11-29 01:22:17

by Chris PeBenito

[permalink] [raw]
Subject: [refpolicy] [PATCH v2 8/8] Fix regexp for templated boolean generation

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 <[email protected]>
> ---
> 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

2017-12-02 12:42:22

by sven.vermeulen

[permalink] [raw]
Subject: [refpolicy] [PATCH v2 8/8] Fix regexp for templated boolean generation

On Wed, Nov 29, 2017 at 2:22 AM, Chris PeBenito via refpolicy
<[email protected]> 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

2017-12-03 21:36:37

by Chris PeBenito

[permalink] [raw]
Subject: [refpolicy] [PATCH v2 8/8] Fix regexp for templated boolean generation

On 12/02/2017 07:42 AM, Sven Vermeulen wrote:
> On Wed, Nov 29, 2017 at 2:22 AM, Chris PeBenito via refpolicy
> <[email protected]> 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