Bug 210261 - "rpmlint iptables" causes traceback
"rpmlint iptables" causes traceback
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: rpmlint (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ville Skyttä
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-10 22:21 EDT by Ralf Corsepius
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: 0.78-2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-15 10:04:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
log from "rpmlint iptables-1.3.5-1.2.i386.rpm > rpmlint-iptables" (398 bytes, text/plain)
2006-10-10 22:21 EDT, Ralf Corsepius
no flags Details
rpmlint iptables-1.3.5-1.2.i386.rpm > /tmp/rpmlint-iptables 2>&1 (115.98 KB, application/octet-stream)
2006-10-10 22:39 EDT, Ralf Corsepius
no flags Details
Draft fix (2.04 KB, patch)
2006-10-11 02:56 EDT, Ville Skyttä
no flags Details | Diff

  None (edit)
Description Ralf Corsepius 2006-10-10 22:21:10 EDT
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
Comment 1 Ralf Corsepius 2006-10-10 22:21:10 EDT
Created attachment 138213 [details]
log from "rpmlint iptables-1.3.5-1.2.i386.rpm > rpmlint-iptables"
Comment 2 Ralf Corsepius 2006-10-10 22:39:58 EDT
Created attachment 138214 [details]
rpmlint iptables-1.3.5-1.2.i386.rpm > /tmp/rpmlint-iptables 2>&1

Now, the correct log ;)
Comment 3 Ralf Corsepius 2006-10-11 00:11:01 EDT
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.
Comment 4 Ville Skyttä 2006-10-11 02:56:24 EDT
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...
Comment 5 Ville Skyttä 2006-10-11 03:03:22 EDT
"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.
Comment 7 Ralf Corsepius 2006-10-12 04:42:22 EDT
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?
Comment 8 Ville Skyttä 2006-10-12 11:36:25 EDT
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.
Comment 9 Ville Skyttä 2006-10-15 10:04:18 EDT
Fixed in 0.78-2.fc*

Note You need to log in before you can comment on or make changes to this bug.