Skip Menu |

This queue is for tickets about the Nagios-Object CPAN distribution.

Report information
The Basics
Id: 46497
Status: open
Priority: 0/
Queue: Nagios-Object

People
Owner: duncan_j_ferguson [...] yahoo.co.uk
Requestors: smithj4 [...] bnl.gov
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 0.21.3
Fixed in: (no value)



Subject: Config parser broken for string attributes that contain a right curly bracket.
The config parser cannot handle string attributes that can contain an arbitrary string of characters, including a right curly bracket [}]. The parser incorrectly assumes that this is the end of the block definition and the remaining attributes for that definition are left unassigned. I created a very simple patch for this bug that will probably work in most cases, but it assumes that the right curly bracket that closes a definition block contains no more important data or comments after it on the same line and is only followed by zero or more white spaces. This was just the simplest solution that worked for our Nagios config, but a proper fix may require a more complicated parser rewrite to be context sensitive and allow right curly brackets within string attributes. ~Jason
Subject: perl-Nagios-Object-Config-broken_string_attributes.patch
diff -uNr Nagios-Object-0.21.3-dist/lib/Nagios/Object/Config.pm Nagios-Object-0.21.3/lib/Nagios/Object/Config.pm --- Nagios-Object-0.21.3-dist/lib/Nagios/Object/Config.pm 2009-02-20 11:30:34.000000000 -0500 +++ Nagios-Object-0.21.3/lib/Nagios/Object/Config.pm 2009-05-28 16:06:49.000000000 -0400 @@ -181,7 +181,12 @@ } # end of object definition - if ( $line =~ /}(.*)$/ ) { + # Some object attributes are strings, which can contain a right-curly bracket and confuse this parser: + # - The proper fix would be to make the parser sensitive to arbitrary string attributes, but I will just + # do it the easy way for now and assume there is no more text on the same line after the right-curly + # bracket that closes the object definition. + #if ( $line =~ /}(.*)$/ ) { + if ( $line =~ /}(\s*)$/ ) { $in_definition = undef; # continue parsing after closing object with text following the '}' $append = $1;
Committed in git - will be in 0.12.4
Thanks for including the patches so quickly and putting out a new release. I just wanted to remind you about the possible danger with this particular patch. Before the patch, the old parser would prematurely close a block definition if one of the attributes contained a right curly bracket, while with this patch, the parser could potentially miss the end of a block definition if the config file contains extra text after the right curly bracket. Although I would naively think that this would be extremely rare, I supposes someone might have a comment after the bracket, which would break the parser. The parser was somewhat complicated, trying to save comments if asked to, so it didn't look like it would be that easy to patch it the correct way, which is why I just made that simple patch. Maybe a warning about what problems the parser may encounter with unusual config files would be warranted, what do you think? We don't have any problems here since I am reading the Nagios objects.cache file directly, instead of trying to read all the system config files. Thanks, ~Jason
Subject: Re: [rt.cpan.org #46497] Config parser broken for string attributes that contain a right curly bracket.
Date: Tue, 2 Jun 2009 13:22:29 -0700
To: bug-Nagios-Object [...] rt.cpan.org
From: Al Tobey <tobert [...] gmail.com>
On Tue, Jun 2, 2009 at 12:57 PM, smithj4@bnl.gov via RT <bug-Nagios-Object@rt.cpan.org> wrote: Show quoted text
>       Queue: Nagios-Object >  Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=46497 > > > Thanks for including the patches so quickly and putting out a new > release.  I just wanted to remind you about the possible danger with > this particular patch. > > Before the patch, the old parser would prematurely close a block > definition if one of the attributes contained a right curly bracket, > while with this patch, the parser could potentially miss the end of a > block definition if the config file contains extra text after the right > curly bracket.  Although I would naively think that this would be > extremely rare, I supposes someone might have a comment after the > bracket, which would break the parser. > > The parser was somewhat complicated, trying to save comments if asked > to, so it didn't look like it would be that easy to patch it the correct > way, which is why I just made that simple patch.  Maybe a warning about > what problems the parser may encounter with unusual config files would > be warranted, what do you think?  We don't have any problems here since > I am reading the Nagios objects.cache file directly, instead of trying > to read all the system config files.
The parser is definitely not ideal. The first version attempted to follow the exact same style as the Nagios 2.x C code but somewhat perlish. At the time, I wanted to preserve comments so I could do complete cycle testing of existing configs, preserving comments since my configuration files had lots of comments. Ultimately, I don't think anybody has used the comment data, so it can be dropped or at least deprecated. I started to write a new parser that was a bit more robust but never finished it. It's probably in source control somewhere in a perldoc block. I looked at using Parse::RecDescent but Nagios's format doesn't really fit very well and P::RD is far too slow for a lot of what people use Nagios::Object for, so I stayed with fairly well optimized RE's. The idea is that it should be able to parse the configuration fast enough to work for command line tools and quick queries without using some kind of intermediate format like most Nagios config managers do. It's fairly close in the current parser and could get a lot better if somebody cares enough to write a new one. -Al Show quoted text
> Thanks, > ~Jason > >