[kde-linux] Re: Alternative to Guarddog

[Duncan]

David Baron posted on Fri, 29 Jul 2011 09:30:13 +0300 as excerpted:

> On Thursday 26 Tamuz 5771 23:27:29 David Baron wrote:
>> I have been using this for years, even under kde4 without the benefit
>> of dcop. Served me well.
>> 
>> With the 3.0 kernels, ipchains is no longer supported. Apparently
>> guarddog used ipchains to run iptables or some such scheme.
>> 
>> Is there something that I can use now with a comprehensible GUI that
>> will read the guarrdog iptables rules to start out? (I found fwbuilder
>> incomprehensible.)
> 
> Actually, the problem is that guarddog's rc.firewall does not test
> kernels "above" 2.6. Some way of fixing that would solve it.

So it's a 3.0-numbering problem in the userspace code, not a problem in 
kernel 3.0 itself.

Thanks.  That makes far more sense.

Latest guarddog stable version 2.6.0, I assume?  What distro?  Do you 
configure and compile the sources from the tarball yourself, or use a 
prebuilt binary package?  If you use a binary package, /could/ you 
compile them yourself?

I downloaded the tarball and see in the docs that rc.firewall is an 
initscript that guarddog should generate, but it didn't have a copy of 
the script in the tarball, so I couldn't examine it to see if I could fix 
the problem.  I don't claim to know C and unless you're on gentoo we're 
not on the same distro, but I know bash reasonably well and may well be 
able to get you a generic fix based solely on the rc script, if it's a 
shellscript as they used to be (tho systemd is set to change that).

Meanwhile, looking at the tarball, I see in guarddogdoc.cpp the place 
where it appears to generate the file, including the kernel version 
test.  A patch should be trivial, if you can build from the sources 
yourself.

Does guarddog replace the system rc.firewall script directly every time 
you run it?  If not, if it spits out the file which you then copy to the 
system location and run the update manually, even if you can't patch and 
build from sources yourself, you should be able to manually modify the 
generated file before you copy it to the system location.  That should be 
trivial as well, but you'd have to do it every time you generated a new 
file to copy over, so patching and building the sources yourself is a 
better fix, provided you are building them yourself already or can do so.

The code in question starts on line 603 of the src/guarddog.cpp file, as 
it appears in the guardog 2.6.0 tarball.

        "# Check for iptables support.\n"
        "if [ -e /proc/sys/kernel/osrelease ]; then\n"
        "  KERNEL_VERSION=`sed \"s/^\\([0-9][0-9]*\\.[0-9][0-9]*\\).*\\$/\
\1/\" < /proc/sys/kernel/osrelease`\n"
        "  if [ $KERNEL_VERSION == \"2.6\" ]; then\n"
        "    KERNEL_VERSION=\"2.4\"\n"
        "  fi;\n"
        "  if [ $KERNEL_VERSION == \"2.5\" ]; then\n"
        "    KERNEL_VERSION=\"2.4\"\n"
        "  fi;\n"


(That one line wrapped.)

If you added above the three lines if/fi checking for kernel version 2.6 
and changing it to 2.4 if it occurs, a similar three lines checking for 
version 3, it should work.

Here's the added commands in bash form.  But I think the {}% characters 
may need \ escaped in the actual cpp file, and I don't know the details 
of that escaping.  If I were running kde3 here I'd probably build guarddog 
from source, testing this as a patch with various escaping until it built 
properly and worked, but since I'm not... you'll have to do that... or 
simply change what I'm guessing is the resulting shell scripts manually, 
accordingly.

        "  if [ ${KERNEL_VERSION%%.*} == \"3\" ]; then\n"
        "    KERNEL_VERSION=\"2.4\"\n"
        "  fi;\n"

Here's how that segment should look with them added (again, you'll have 
to adjust escaping for the {}% chars on the first added line as needed):

       "# Check for iptables support.\n"
        "if [ -e /proc/sys/kernel/osrelease ]; then\n"
        "  KERNEL_VERSION=`sed \"s/^\\([0-9][0-9]*\\.[0-9][0-9]*\\).*\\$/\
\1/\" < /proc/sys/kernel/osrelease`\n"
        "  if [ ${KERNEL_VERSION%%.*} == \"3\" ]; then\n"
        "    KERNEL_VERSION=\"2.4\"\n"
        "  fi;\n"
        "  if [ $KERNEL_VERSION == \"2.6\" ]; then\n"
        "    KERNEL_VERSION=\"2.4\"\n"
        "  fi;\n"
        "  if [ $KERNEL_VERSION == \"2.5\" ]; then\n"
        "    KERNEL_VERSION=\"2.4\"\n"
        "  fi;\n"
 
FWIW, ${var%%pattern} in bash simply tells it to test whether the END of 
the string in $var matches pattern, deleting it if so, and returning the 
rest.  So what that bit does is reduce the "3.0", "3.1" for the next 
version, etc, to simply "3" and tests whether that's a 3 or a 2 or 
whatever.  Otherwise, you'd have to re-patch for every new 3.x kernel 
release, 3.1, 3.2, etc, since the changing version changed from the third 
spot (2.6.x) to the second (3.x).

I hope that helps...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman