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

[Emeric POUPON]

hello,

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.

Regards,

Emeric

----- 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
>> 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