-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BF: fail2ban client can't handle multi word setcinfo or action[*] values #134
Conversation
…re possible and has different meanings
…an,check] and for setcinfo too
@@ -189,7 +189,7 @@ def __commandSet(self, command): | |||
elif command[1] == "setcinfo": | |||
act = command[2] | |||
key = command[3] | |||
value = command[4] | |||
value = " ".join(command[4:]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why bother exactly if any given cmdline positional argument could be wrapped into " " or ' ' ?
I do see it as a possible improvement, but that then also requires documentation (--help output) clarification... but still wonder if it is worth it at all
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why bother exactly if any given cmdline positional argument could be wrapped into " " or ' ' ?
Because action* is almost always more that one word. Because this is the only case a wrapped argument is needed. Its still not the nicest but it gives consistent results. Because fail2ban currently discarding arguments and not reporting so much as an error.
The testcase:
./fail2ban-client -c config/ -s /tmp/f2b.sock -i start add test pyinotify set test addaction iptables set test actionban iptables echo >> /tmp/ban set test actionunban iptables echo >> /tmp/unban get test actionban iptables get test actionunban iptables
Currently this records only the echo as the action.
but that then also requires documentation (--help output) clarification..
So
sets the start command of the action for . Quote with "" or '' if more than a one word command is required.
I do see it as a possible improvement,
but still wonder if it is worth it at all
make up your mind. Unless you knew about quoting you've got a barely usable set action* client interface.
BF: fail2ban client can't handle multi word setcinfo or action[*] values
ok -- looked all good... so I merged to not keep it away for too long but still would be nice to signal this feature (of joining multiple positional args). may be via '<>' instead of '' in help output with a minimalistic description for that? |
Is there a need? Looking in common/protocol.py I see VALUE, CMD, REGEX and maybe ACTION and JAIL that are likely to contain spaces. If we redo the parsing to closely couple to the commands here we can grab the remainder of the line as the last positional argument and this will solve VALUE, CMD and REGEX. Is supporting spaces in ACTION and JAIL in the command line something you'd like to support? <> is already used in the action commands for things like and I don't find it as something that I'd intuitively separate arguments with. |
BF: allow more than single word for command action[start,stop,ban,unban,check] and for setcinfo too in fail2ban-client. Previously a set
BF: general Exception catch was excessive. Only IOError and OSError are possible and have different meanings