Red Hat Bugzilla – Bug 210261
"rpmlint iptables" causes traceback
Last modified: 2007-11-30 17:11:45 EST
Per Ville's request, this PR has been split out from https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209889 Description of problem: Running rpmlint iptables on fc5 causes a traceback. The same occurs with when using rpmlint directly on the iptables-rpm as having been shipped with FC5: rpmlint iptables-1.3.5-1.2.i386.rpm Version-Release number of selected component (if applicable): rpmlint-0.78-1.fc5.1 How reproducible: Deterministically. Steps to Reproduce: rpmlint iptables-1.3.5-1.2.i386.rpm
Created attachment 138213 [details] log from "rpmlint iptables-1.3.5-1.2.i386.rpm > rpmlint-iptables"
Created attachment 138214 [details] rpmlint iptables-1.3.5-1.2.i386.rpm > /tmp/rpmlint-iptables 2>&1 Now, the correct log ;)
The cause seems to be the iptables package containing this construct below in /etc/rc.d/init.d/iptables: ... IPTABLES=iptables ... VAR_SUBSYS_IPTABLES=/var/lock/subsys/$IPTABLES ... The shell_variable expansion code intThe syssys check in /usr/share/rpmlint/InitScriptCheck.py (near line 135 in rpmlint-0.78-1.fc5.1) doesn't seem to able to correctly expand $IPTABLES in VAR_SUBSYS_IPTABLES=/var/lock/subsys/$IPTABLES and recurses into an infinite recursion.
Created attachment 138221 [details] Draft fix Yep, there are several bugs in the rpmlint code whose combined effect is this endless recursion plus practically failure to expand any shell values in init scripts at all. First, InitScriptCheck.py passes only the _line_ in the init script where the variable occurs to the shell variable expansion routine. It needs to pass the whole script, otherwise there's no hope of getting anything usefully expanded. Second, constructs such as "FOO=$FOO" in the shell variable expansion routines do cause endless recursion. Third, VAR_SUBSYS_IPTABLES=/var/lock/subsys/$IPTABLES is indeed the line that causes recursion in this case. The issue is that rpmlint effectively parses the assignment as IPTABLES=/var/lock/subsys/$IPTABLES - there's a missing start boundary check in assign_regex in shell_var_value() - so it ends up in the 2nd case above. The attached patch should fix all of the above, however I see the shell variable expansion routines are still pretty feeble and it's easy to construct cases where they fail to do the expansion correctly. Dunno if they're worth having/fixing in the first place, but they're already in and this patch shouldn't at least make them any worse...
"orig = None" in the signature of shell_var_value() in the patch in comment 4 is a leftover from some earlier local tests, it will be removed before applying this anywhere.
Applied upstream as http://rpmlint.zarb.org/cgi-bin/trac.cgi/changeset/1286 http://rpmlint.zarb.org/cgi-bin/trac.cgi/changeset/1287 http://rpmlint.zarb.org/cgi-bin/trac.cgi/changeset/1288
OK, I gave your patch a try. The positive side: "rpmlint -a", "rpmlint iptables", "rpmlint iptables*.rpm" don't bomb out anymore. On the negative side: As you say, this "shell expansion" is a semi-functional hack. I am having doubts if this is the "right approach (tm)" to the problem rpmlint is trying to solve (consider shell functions, consider "sourcing functions from inside init scripts). So, I am I correct in expecting you to update rpmlint in FE5 to render "rpmlint -a" functional again?
Yep, I'm just going to have a quick look at bug 210110 to see if there's an easy fix for it, and then ping other upstream folks to see if they agree the accumulated fixes over the past few days are worth a new release (and if not, will ship a patched package in the meantime). See also http://rpmlint.zarb.org/cgi-bin/trac.cgi/ticket/51 for a request for comments regarding removal of the shell var expansion stuff.
Fixed in 0.78-2.fc*