Commit Message

When the lexer encounters an unexpected character in a policy source file, it prints a warning, discards the character and moves on. In some build environments, these characters could be a symptom of an earlier problem, such as unintended results of expansion of preprocessor macros, and the ability to have the compiler halt on such issues would be helpful for diagnosis.
Signed-off-by: Daniel Burgener <Daniel.Burgener@microsoft.com>
---
checkpolicy/checkmodule.8 | 3 +++
checkpolicy/checkmodule.c | 10 ++++++++--
checkpolicy/checkpolicy.8 | 3 +++
checkpolicy/checkpolicy.c | 9 +++++++--
checkpolicy/policy_scan.l | 4 ++++
5 files changed, 25 insertions(+), 4 deletions(-)

Comments

On Thu, Mar 5, 2020 at 1:40 PM Daniel Burgener
<dburgener@linux.microsoft.com> wrote:
>> When the lexer encounters an unexpected character in a policy source file, it prints a warning, discards the character and moves on. In some build environments, these characters could be a symptom of an earlier problem, such as unintended results of expansion of preprocessor macros, and the ability to have the compiler halt on such issues would be helpful for diagnosis.>> Signed-off-by: Daniel Burgener <Daniel.Burgener@microsoft.com>
I'm trying to remember why this particular case (unmatched character
in the lexer) isn't already a fatal error.
If there isn't a real reason for it, we could alternatively just
switch it to use yyerror() in that case.
Otherwise, your description suggests that you only want to make that
particular case a fatal error; are you sure
you want to treat all warnings as fatal errors?

On 3/6/20 8:57 AM, Stephen Smalley wrote:
> On Thu, Mar 5, 2020 at 1:40 PM Daniel Burgener > <dburgener@linux.microsoft.com> wrote:>> When the lexer encounters an unexpected character in a policy source >> file, it prints a warning, discards the character and moves on. In >> some build environments, these characters could be a symptom of an >> earlier problem, such as unintended results of expansion of >> preprocessor macros, and the ability to have the compiler halt on >> such issues would be helpful for diagnosis. Signed-off-by: Daniel >> Burgener <Daniel.Burgener@microsoft.com> > I'm trying to remember why this particular case (unmatched character > in the lexer) isn't already a fatal error. If there isn't a real > reason for it, we could alternatively just switch it to use yyerror() > in that case. Otherwise, your description suggests that you only want > to make that particular case a fatal error; are you sure you want to > treat all warnings as fatal errors?
That's a bug in the description rather than the code. That particular
case is what caused me to want this option, but my intent was to add an
ability to treat all warnings as errors. I can resubmit with a better
message if you'd like.
I'm not sure why the behavior is that that particular case is a
warning. Git blame shows it as going back to the import from svn, so
it's been that way for a while. I'd think that --werror would be
helpful either way. If no one has a reason for this particular case to
be a warning rather than an error, I can submit a patch for that change
as well.
-Daniel

It looks to me like the only warnings are for:
- Conflicting expandattribute rules (which will default to false)
- A dontaudit rule that uses ~ for its permissions
- Stating that role dominance is deprecated
- Unexpected character: @ $ % & _ + = \ | " ' < > ?
It might make more sense just to make the unexpected character case to
always be an error.
Jim
On Fri, Mar 6, 2020 at 9:16 AM Daniel Burgener
<dburgener@linux.microsoft.com> wrote:
>> On 3/6/20 8:57 AM, Stephen Smalley wrote:> > On Thu, Mar 5, 2020 at 1:40 PM Daniel Burgener> > <dburgener@linux.microsoft.com> wrote:> >> When the lexer encounters an unexpected character in a policy source> >> file, it prints a warning, discards the character and moves on. In> >> some build environments, these characters could be a symptom of an> >> earlier problem, such as unintended results of expansion of> >> preprocessor macros, and the ability to have the compiler halt on> >> such issues would be helpful for diagnosis. Signed-off-by: Daniel> >> Burgener <Daniel.Burgener@microsoft.com>> > I'm trying to remember why this particular case (unmatched character> > in the lexer) isn't already a fatal error. If there isn't a real> > reason for it, we could alternatively just switch it to use yyerror()> > in that case. Otherwise, your description suggests that you only want> > to make that particular case a fatal error; are you sure you want to> > treat all warnings as fatal errors?>> That's a bug in the description rather than the code. That particular> case is what caused me to want this option, but my intent was to add an> ability to treat all warnings as errors. I can resubmit with a better> message if you'd like.>> I'm not sure why the behavior is that that particular case is a> warning. Git blame shows it as going back to the import from svn, so> it's been that way for a while. I'd think that --werror would be> helpful either way. If no one has a reason for this particular case to> be a warning rather than an error, I can submit a patch for that change> as well.>> -Daniel>

On Fri, Mar 6, 2020 at 9:16 AM Daniel Burgener
<dburgener@linux.microsoft.com> wrote:
>> On 3/6/20 8:57 AM, Stephen Smalley wrote:> > On Thu, Mar 5, 2020 at 1:40 PM Daniel Burgener> > <dburgener@linux.microsoft.com> wrote:> >> When the lexer encounters an unexpected character in a policy source> >> file, it prints a warning, discards the character and moves on. In> >> some build environments, these characters could be a symptom of an> >> earlier problem, such as unintended results of expansion of> >> preprocessor macros, and the ability to have the compiler halt on> >> such issues would be helpful for diagnosis. Signed-off-by: Daniel> >> Burgener <Daniel.Burgener@microsoft.com>> > I'm trying to remember why this particular case (unmatched character> > in the lexer) isn't already a fatal error. If there isn't a real> > reason for it, we could alternatively just switch it to use yyerror()> > in that case. Otherwise, your description suggests that you only want> > to make that particular case a fatal error; are you sure you want to> > treat all warnings as fatal errors?>> That's a bug in the description rather than the code. That particular> case is what caused me to want this option, but my intent was to add an> ability to treat all warnings as errors. I can resubmit with a better> message if you'd like.>> I'm not sure why the behavior is that that particular case is a> warning. Git blame shows it as going back to the import from svn, so> it's been that way for a while. I'd think that --werror would be> helpful either way. If no one has a reason for this particular case to> be a warning rather than an error, I can submit a patch for that change> as well.
Ok. I have no objections to your patch, just wanted to make sure it
is doing what you really want it to do.
I'd also be willing to accept a patch to make unexpected characters fatal.

On Thu, Mar 5, 2020 at 1:40 PM Daniel Burgener
<dburgener@linux.microsoft.com> wrote:
>> When the lexer encounters an unexpected character in a policy source file, it prints a warning, discards the character and moves on. In some build environments, these characters could be a symptom of an earlier problem, such as unintended results of expansion of preprocessor macros, and the ability to have the compiler halt on such issues would be helpful for diagnosis.>> Signed-off-by: Daniel Burgener <Daniel.Burgener@microsoft.com>
Acked-by: Stephen Smalley <sds@tycho.nsa.gov>

On Mon, Mar 9, 2020 at 9:58 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>> On Thu, Mar 5, 2020 at 1:40 PM Daniel Burgener> <dburgener@linux.microsoft.com> wrote:> >> > When the lexer encounters an unexpected character in a policy source file, it prints a warning, discards the character and moves on. In some build environments, these characters could be a symptom of an earlier problem, such as unintended results of expansion of preprocessor macros, and the ability to have the compiler halt on such issues would be helpful for diagnosis.> >> > Signed-off-by: Daniel Burgener <Daniel.Burgener@microsoft.com>>> Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
Applied.