[strongSwan-dev] Removed SA/policies flush from starter
emeric.poupon at stormshield.eu
Wed Jul 6 09:56:20 CEST 2016
Thanks for these valuable explanations.
For now I will go for the scripts+patch solution. When we migrate from starter to swanctl, we will remove the patch.
----- Original Message -----
> From: "Tobias Brunner" <tobias at strongswan.org>
> To: "Emeric POUPON" <emeric.poupon at stormshield.eu>
> Cc: dev at lists.strongswan.org
> Sent: Friday, 1 July, 2016 14:51:57
> Subject: Re: [strongSwan-dev] Removed SA/policies flush from starter
>> 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
>> 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.
More information about the Dev