On 02/18/2018 06:30 PM, Marek Marczykowski-Górecki wrote:
Hash: SHA256

On Sun, Feb 18, 2018 at 01:10:44PM -0500, Chris Laprise wrote:
I'm thinking about posting a PR to have qubes-firewall raise errors whenever
a firewall script from qubes-firewall-user-script or qubes-firewall.d
returns an error code.

The object is to provide a way to make the qubes-firewall service fail when
firewall scripts encounter an error. On failure, the result would be that
forwarding (or networking) is disabled and any units bound to qubes-firewall
would not run.

Default behavior would be little different than it is now, given that shell
scripts are fault-tolerant. But script authors will have the option of using
"set -e" or "exit 1" etc. so the service goes into a failed state.

Problems like crashed qubes-firewall are very annoying and it isn't easy
to find where such service have crashed. Also, script exiting with
non-zero code can happen for various reasons, including misusing "[
condition ] && action" syntax. I've seen far to many errors like that.

The intention is for a script author who wants net enabled only if firewall script runs exactly right... they can use "set -e". Otherwise the service wouldn't be affected by an error.

As for finding errors when they occur, looking at journalctl is pretty informative since related lines about failure are highlighted and twice mention the method i.e. "self.run_user_script". I was wondering if the service could also do a notify-send, or even call a qubes-rpc method that merely informs about VM state in such a case.

Alternately, instead of failing the service could handle the error by simply logging it and disabling forwarding for the proxyVM. Another service (post-misc?) might display an informational popup about forwarding state.

But if the script author know what he/she is doing, having option to
fail closed is a good idea. What about choosing en exit code that would
cause the effect you propose? And let that not be 1. This could allow
both: fail closed for conscious user, and harder to break the setup by
stupid error. The idea is inspired by Restart*ExitStatus= settings of
systemd.service and git bisect run.

I think this would put a burden on the script writer to improvise (and not accidentally undermine) their own facsimile of try/catch so that sending the special exit code is possible. In this case, the script writer has already done (precariously) 95% of what is needed to prevent the proxyvm from going online anyway. IOW

I'm asking about this because I started to put checks for firewall rules in the qubes-tunnel startup code, but it seems kludgey to have a non-firewall script check for specific rules. Its cleaner to just enforce error checking in the first place.


Also... looking at how qubes-firewall fails at that point, its different than the 3.2 behavior I remember where enabling of forwarding followed in sequence after the user script. When the R4.0 service fails at run_user_script the system continues with forwarding enabled which seems suboptimal.


Chris Laprise, tas...@posteo.net
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to