varnishcache
Load VEXTs in manager
We foresaw this when we added VEXTs: while storage VEXTs have been happy with loading in the worker process, to support pluggable acceptors, VEXTs need to be present in the manager for opening privileged ports etc.
An implementation of a pluggable excceptor as a VMOD can be found in https://github.com/nigoroll/varnish-cache/commits/plugable_acceptors_rebase/, which is based upon #3976
I'm very much in favor for this change, this also allows us to define transports (like proxy) as VEXTs (without hacking too much)
», VEXTs need to be present in the manager for opening privileged ports etc.«
This is simply not true.
VEXT's get a chance to bite before privileges are dropped right after the fork().
bugwash: I apologized for my mistake on the privileges, I probably had too much in mind what the solaris jail does, and need to look again at the privilege separation stuff.
Other than that, if vexts can't be loaded before -a processing, they need a different way to configure
», VEXTs need to be present in the manager for opening privileged ports etc.«
This is simply not true.
VEXT's get a chance to bite before privileges are dropped right after the fork().
I had another look. The problem is not that vext_load() happens in the child, the problem is that the initial VCA configuration including bind() happens in mgt, and the natural approach (at least in my mind) is that a VCA VEXT should be configured like any other VCA.
To allow VEXT VCAs but no VEXTs in mgt, we would need to move the VCA_*() calls from mgt main() to the child. To move VCA_Arg(), mgt would need to pass the respective argvs to the child, the child would parse arguments and fatal error scenarios (basically bind() failures) would result in a Child failed to launch error.
It is my understanding that we have so far been operating under the principle of detecting configuration problems before even starting the child, in particular by test-loading the VCL.
Do we want to (at least partly) give up this principle?
One other example I see where loading VEXTs in mgt makes sense is a keyserver sidecar process. I think it should have a similar lifetime as mgt and be controlled by mgt. It needs to start with elevated privileges to load a wrapping key and then drop them.
What would be reasons to for keeping VEXTs in the child only?
I have added a change to this PR which is somehow unrelated, but needs the ability to plug an acceptor. See https://github.com/varnishcache/varnish-cache/issues/4169#issuecomment-2453476501
I am going to continue working with the code in this ticket due to lack of alternatives, but bugwash agreed that this PR will not go in because we want to keep VEXTs out of the mgt process. We need an alternative concept, which @bsdphk wants to write up. Thank you!
edit: I think that for any alternative concept, we will also need to move the existing acceptors from mgt to worker, if they are to act en par with VEXT provided acceptors.
FTR: In light of the existence of LD_PRELOAD, does it really make sense to try to "prevent" loading code into mgt?