[strongSwan-dev] Removed SA/policies flush from starter

[Tobias Brunner]

> This doesn't work on Linux as the scripts run after the plugins have
> been initialized so `ip xfrm` would flush the bypass policies set on the
> UDP sockets used by the daemon.

I have to correct myself here.  While socket-specific policies are
listed in `ip xfrm policy` they are not actually removed when flushing
all policies via XFRM.  So as long as
charon.plugins.kernel-netlink.port_bypass is disabled (the default) this
works fine on Linux too (except for the same race with starter).

>>> Wouldn't it be safer to commit this by the way?
>>
>> No, then we couldn't e.g. run swanctl commands to load connections, as
>> the vici plugin wouldn't be able process the requests.
>>
> Then for the startup scripts I guess there is the same race using swanctl or starter?
> How can one be sure the scripts are completed before loading the connections?

By loading the connections with a start script (e.g. `swanctl --load-all
--noprompt`) that runs after the two others (scripts are executed in the
order defined in the start-scripts section).

Or when using charon-systemd (not on FreeBSD obviously as it does not
use systemd) load the connections via ExecStartPost (as the
strongswan-swanctl service unit does).  This command runs after the
daemon signals its readiness to systemd, which happens after the scripts
ran.  Actually, using ExecStartPost is not even necessary as starting
the daemon with systemd will block until it is ready (and start scripts
were executed) so any swanctl command that's executed directly after
e.g. `systemctl start` will run after the start scripts.

> By the way, why does starter manage to send the connections with my patch?
> I thought the socket was created but no thread was actually accepting on it. Isn't it the same with the vici plugin?

Yes, exactly the same.  With the patch the scripts will run and starter
will concurrently write connection data to the socket.  But here it
doesn't matter if nobody is reading from the socket yet as the scripts
won't block.  After running them the threads are started and the data is
read from the socket.
However, the start-scripts facility was mainly added to run swanctl
commands on systems where starter is not used (Windows, systemd).  And
swanctl commands are synchronous, i.e. they block until they get a
reply.  So the patch would create a deadlock if swanctl commands are run
as start scripts:  swanctl would wait for a response, the daemon's main
thread would wait for swanctl to terminate and therefore couldn't
continue to start the other threads that would allow the vici plugin to
respond to the swanctl request.

Regards,
Tobias