Issue #14 new

Auto run config specified command on firewall open/close

created an issue

It would be really cool if you could add three config entries e.g.

autorun_while_open = <string>

autorun_on_open = <string>

autorun_on_close = <string>

Each of the strings specify a shell command which is run on the appropriate event. autorun_while_open would spawn the child process and kill it when the firewall is closed.

This way, on firewall open, I could start an SSH tunnel for SMTP so I can still use SUN's mailserver from outside, and when I close the firewall, the tunnel is closed to.

Comments (6)

  1. sirlark reporter

    Implemented this myself fairly quickly (I've attached a patch file your perusal). It's fairly robust; I've tested non-existent executables, commands that return an error, and successful commands, including the mail tunnel. Having set up my keys, "ssh -N -L" works perfectly :)

    Hope this helps.

  2. Janto Dreijer repo owner

    Thanks! I've integrated your changes (c01e06d591d9 ) with the development version. I also made a few changes (846b5f7e6c87 ) of my own, to further minimize the effect on normal firewall behavior if a command fails. And some backwards compatibility things.

    I'll put it in the deb distribution after I've played with it and convinced myself it doesn't break anything. There are some issues I'm unsure of. For example the run_while_open command doesn't report an error if there is something wrong with the command. Not sure why not.

    For your application I suggest that you check if it still behaves the way you expect it to. The primary differences are:

    • I'm using run_on_open etc instead of autorun_on_open etc. Just my personal taste.
    • The run_while_open subprocess is now created only once in the time between the firewall is opened and closed. In your code it is recreated each time open_firewall() is called. I think that was a bug?
    • The run_while_open_subprocess will terminate on close_firewall call even if the firewall wouldn't close or run_on_close failed. Just a bit of robustness.
    • I've unified some of the CalledProcessError and OSError exceptions ... not sure if that was a good idea. I have a suspicion it might break for some things, but I can't produce an example.
  3. Janto Dreijer repo owner
    • changed status to open

    I'm reopening this issue. The functionality is in the new deb, but I still need to document it. And there's some things I need to decide on.

    Do we rather need run_before_open, run_after_open, run_before_close and run_after_close?

    I'm also working on more daemon like behavior for pynetkey, and some of the use cases for your feature might be better served by that once the daemon is fully implemented. See issue #17 if you want to keep track of that.

    Also, I had to wrap run_while_open in a thread to catch other errors that are possible. I haven't yet put this in the deb file, but I will with the next update.

  4. sirlark reporter
    • changed status to new

    My initial reason for having a run_while_open was because I couldn't figure out a way of getting the pid of the child process consistently, especially since the 'command' specified was executed via a shell and could conceivably spawn multiple processes. If you can find a way around this then run_before/after_open/close makes more sense.

  5. Log in to comment