[petsc-dev] MacOS firewall annoyance while running tests + solution
Hapla Vaclav
vaclav.hapla at erdw.ethz.ch
Mon Aug 31 04:10:36 CDT 2020
On 29 Aug 2020, at 05:44, Satish Balay via petsc-dev <petsc-dev at mcs.anl.gov<mailto:petsc-dev at mcs.anl.gov>> wrote:
Likely firewall is disabled.
I've recently rebuild a bunch of boxes - and don't remember explicity disabling firewall. [well I did something to enable ssh - maybe that was disabling firewall]
I see the firewall is disabled on all of them
balay at ypro ~ % defaults read /Library/Preferences/com.apple.alf globalstate
0
balay at ypro ~ %
Ref: https://raymii.org/s/snippets/OS_X_-_Turn_firewall_on_or_off_from_the_command_line.html
BTW: Perhaps the following setting will prevent popups? [but it might break stuff that need network?]
sudo defaults write /Library/Preferences/com.apple.alf globalstate -int 2
2 = on for essential services
https://discussions.apple.com/thread/3148672
So I don't think that's an option for normal people - I don't think anybody is keen to limit the network functionality on their laptop (e.g. disable Spotify) just for sake of PETSc testing.
So I still think the automated targeted firewall rules I propose are better for most guys. The question is how much automated solution we want to offer.
Vaclav
Satish
On Fri, 28 Aug 2020, Matthew Knepley wrote:
Which OS is this? It does not happen on my Catalina.
Thanks,
Matt
On Fri, Aug 28, 2020 at 10:52 PM Barry Smith <bsmith at petsc.dev<mailto:bsmith at petsc.dev>> wrote:
On Aug 28, 2020, at 3:47 PM, Jed Brown <jed at jedbrown.org<mailto:jed at jedbrown.org>> wrote:
"Hapla Vaclav" <vaclav.hapla at erdw.ethz.ch<mailto:vaclav.hapla at erdw.ethz.ch>> writes:
On MacOS, maybe you also have lots of firewall popups
appearing/disappearing when running tests like
Do you want the application "ex29" to accept incoming network connections?
Is there a way to express that the application does not need (should not
accept) incoming connections?
Yes, this also seems to work:
sudo $$FW --block $$APP
instead of
sudo $$FW --unblock $$APP
The parallel program still runs correctly to conclusion without the popup.
So my conclusion is that at listen() or some later system call it always
pops up the window (unless the user as already blocked or unblocked the
executable) without regard to whether an outside (from the machine)
connection to the process is attempted.
The routine has an undocumented option -a <listen or accept> when you run
with
/usr/libexec/ApplicationFirewall/socketfilterfw -d -a accept
it prints ASKWHENACCEPT which seems to indicate it will delay the popup
until an accept is called but I can't confirm this because the debugger
never stops in accept on one process but the popup still comes up so this
argument may be ignored.
If I were Junchao I would not do the popup until the code tried to
accepted an EXTERNAL connection (the lazy evaluation) but I cannot get it
to behave this way.
If I disconnect from the network I still get the popups.
The pop up is asynchronous also, when the popup is still up the program
keeps run (even in parallel) and ends normally. Then the popup disappears.
Apple could make this friendly without hurting security but then Apple
never cared about external developers for the Mac.
Normalizing sudo during build/testing seems really bad.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20200831/4cb37d54/attachment.html>
More information about the petsc-dev
mailing list