zebra: separate zebra ZAPI server open and accept

[mjstapp]

It sounds from #16747 as if it's possible for zebra to get privs wrong when it sets up its zapi server socket when running in privs-per-process mode. The current zserv code opens and starts listening on that server socket pretty late during startup, since zebra needs to be ready to do what clients start asking it to do.
This PR separates zebra's ZAPI server socket handling into two phases: an early phase that opens the socket, and a later phase that starts listening for client connections. The early 'open' phase is called quite early, before other zebra subsystems are started. The 'start' phase is still called later on.

[KanjiMonster]

Currently giving this a spin with the shell script from #16747, looks good so far.

[KanjiMonster]

At least a quick smoke-test with our internal testing didn't show any new failures (with this patch and #16749 applied on top of 9.1.2).

[ton31337]

@Mergifyio backport dev/10.2 stable/10.1 stable/10.0 stable/9.1 stable/9.0

[mergify]

backport dev/10.2 stable/10.1 stable/10.0 stable/9.1 stable/9.0

🟠 Waiting for conditions to match

• merged [📌 backport requirement]

[mjstapp]

rebased to latest upstream

[mjstapp]

Fixed a path that's called once per-netns, not once per startup.

[mwinter-osr]

CI:rerun Check ANVL results again

[KanjiMonster]

Might be worth to point out that this does not fix the core issue, but only works around it.

The core issue is that frr_with_privs(NULL) does nothing meaningful, especially does not ensure that code is run without privileges in the per-process privileges case.

While zebra's zserv is the only user of frr_with_privs(NULL), I wouldn't be surprised if there are other places that also assume that things are done without privileges, but don't use frr_with_privs(NULL).

[mjstapp]

Sure - I'm not claiming to have fixed everything, just wanted to try to help with the immediate symptom, I guess.
I've opened a more general issue about this more general ... issue: #17420

Might be worth to point out that this does not fix the core issue, but only works around it.

The core issue is that frr_with_privs(NULL) does nothing meaningful, especially does not ensure that code is run without privileges in the per-process privileges case.

While zebra's zserv is the only user of frr_with_privs(NULL), I wouldn't be surprised if there are other places that also assume that things are done without privileges, but don't use frr_with_privs(NULL).

[KanjiMonster]

Sure - I'm not claiming to have fixed everything, just wanted to try to help with the immediate symptom, I guess. I've opened a more general issue about this more general ... issue: #17420

Might be worth to point out that this does not fix the core issue, but only works around it.
The core issue is that frr_with_privs(NULL) does nothing meaningful, especially does not ensure that code is run without privileges in the per-process privileges case.
While zebra's zserv is the only user of frr_with_privs(NULL), I wouldn't be surprised if there are other places that also assume that things are done without privileges, but don't use frr_with_privs(NULL).

Just to be clear this wasn't meant as a critique to the approach; I think the solution is right for now and should be merged, as it does fix a race condition.