On 02/03/2018 01:31 PM, donoban wrote:
On 02/03/2018 01:10 PM, David Hobach wrote: When you add temporary access for a AppVM, a service and a timer are created for that VM:- qubes-reload-firewall@(VM-Name).timer - qubes-reload-firewall@(VM-Name).service then the timer is enabled. 1min later the timer is fired and it enables the service, the service checks if the rule has expired and if yes it updates the iptables rules and stops the timer. The problem without "OnUnitActiveSec=1m" is that the timer is not fired anymore (at least on my computer), it goes to "elapsed" state, and the service is not enabled never again and the VM still with full access forever. Maybe is some problem with systemd. I am not sure about the desired effect of OnActiveSec alone.
Honestly I don't really understand why systemd was used at all for that functionality.
Anyway I did test your suggestion and unfortunately it didn't reliably work for me: 1/3 times it worked and that seemed to be the random chance of it working that you also mentioned in your first bullet point. In fact I followed your steps for 2m, tested it again after daemon-reload & it the connection went through, then attempted 2 times after a reboot (the service edit was still there) for which it worked once.
My 3.2 test machine was pretty outdated though, i.e. maybe it also depends on the systemd version running.
Feel free to update the ticket though. In particular the observation that there is a certain chance for it to work as expected is rather interesting.
Whether or not an ongoing connection such as a continuing ping should be broken after timeout is a different topic btw - I guess there's some RELATED, ESTABLISHED iptables rule that keeps it up.
I also just noticed that the feature seems to exist in the 4.0 GUI. Maybe I'll test that as well...
In total however using sth like qvm-firewall [allow all] && sleep [time] ; qvm-firewall [remove allow all] currently seems to be more reliable. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to email@example.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/57292981-35a3-07ea-3f22-33231140f54e%40hackingthe.net. For more options, visit https://groups.google.com/d/optout.
Description: S/MIME Cryptographic Signature