From: Yeonggi Kim <[email protected]>
Hi,
While migrating a deployment from 3.2 to 3.4 we noticed that a "ring"
section whose "server" line targets a UNIX socket, a common way to feed
a local "log-forward" section, is now rejected at parse time:
'server buf1/srv1' : log server address family not supported for log
backend server
This used to work fine before 3.3. It comes from 23e5f18b8 ("MEDIUM:
sink: change the sink mode type to PR_MODE_SYSLOG"), which tags a sink's
internal forward_px with PR_MODE_SYSLOG for compatibility-check purposes
only, but as a side effect also subjects it to _srv_check_proxy_mode()'s
log-backend address-family checks that were only meant for real
user-configured "mode log" backends.
While investigating we also found that the same code path lets a DGRAM
address through unchecked (e.g. "server s1 [email protected]:1514"), which
then segfaults at runtime in conn_select_mux_be() -> proto_is_quic(),
since a ring's forward_px only ever expects a STREAM transport. Patch
1/2 closes both by reusing the PR_CAP_INT flag that 40eb1dd13 already
sets on this exact class of internal proxies. Patch 2/2 adds a reg-test.
This should be backported up to 3.3, but only where 23e5f18b8 and
40eb1dd13 are already backported: without the latter, PR_CAP_INT is not
set on forward_px and the fix becomes a silent no-op.
Note: an earlier attempt to send this was mangled by a webmail client
(base64) and never made it to the list. Apologies if it shows up twice.
Yeonggi Kim (2):
BUG/MEDIUM: server: skip log backend addr checks for internal proxies
REGTESTS: log: check that a ring's internal server may target a UNIX
socket
reg-tests/log/ring_unix_log_forward.vtc | 83 +++++++++++++++++++++++++
src/server.c | 10 ++-
2 files changed, 91 insertions(+), 2 deletions(-)
create mode 100644 reg-tests/log/ring_unix_log_forward.vtc
--
2.52.0
