Re: [Sshguard-users] xtables lock

[Kevin Z. <kev...@gm...>]

Hi James,

Thanks for analyzing and reporting the issue.

On 03/24/2015 16:19, James Harris wrote:
> But it doesn't look like that is enough.  I suspect libvirtd has
> 'finished' starting up but has not completed the iptable changes it
> requires.  What about adding "-w" to the iptables firwall commands?  The
> downside is the command could block for a while. Should run_command()
> fork/exec and wait for a specific timeout before giving up on the
> command? Is blocking indefinitely acceptable, or is this all on deck for
> the libev rewrite?

It doesn't sound like the xtables lock is held for a long time; if
you're feeling adventurous you can try adding "-w" (I can give you a
patch to test if you wish) and see what happens.

If the firewall command blocks, SSHGuard will stop processing new log
entries until system() returns. On a practical note, if xtables is
really locked then returning immediately doesn't gain anything; the next
attack cannot be blocked, so we might as well wait.

This would not be fixed by the libev rewrite, although sometime in the
distant future firewall commands may be executed in a separate process.
However, even this does not solve the underlying issue; although
SSHGuard will continue to run, nothing will be blocked.

I'm not familiar with, nor do I run iptables, but it sounds like adding
"-w" doesn't have huge issues and makes sense.

Thanks,
Kevin Zheng

-- 
Kevin Zheng
kev...@gm... | ke...@kd... | PGP: 0xC22E1090