]> git.kaiwu.me - haproxy.git/commitdiff
BUG/MEDIUM: server: skip log backend addr checks for internal proxies
authorYeonggi Kim <yg.kim@navercorp.com>
Tue, 22 Sep 2026 12:10:12 +0000 (21:10 +0900)
committerAmaury Denoyelle <adenoyelle@haproxy.com>
Mon, 28 Sep 2026 12:46:38 +0000 (14:46 +0200)
23e5f18b8 ("MEDIUM: sink: change the sink mode type to PR_MODE_SYSLOG")
tagged a sink's forward_px (the internal proxy backing a "ring" section)
with PR_MODE_SYSLOG "for compat checks" purposes, stating no behavior
change was expected. This unintentionally made ring's internal "server"
line subject to _srv_check_proxy_mode()'s log-backend compatibility
checks, which were only meant for real "mode log" backends.

Internal proxies (PR_CAP_INT) now fall through to the regular "else"
branch, i.e. the generic STREAM-transport check instead of the
family/DGRAM checks meant for log backends. Two independent
consequences follow from this, both regressions introduced by
23e5f18b8:

1. A "ring" section whose server targets a UNIX socket (a common
   pattern to feed a local "log-forward" section) is rejected at parse
   time with "log server address family not supported for log backend
   server", even though this worked fine before 23e5f18b8.

   Reproducer:

       global

       ring buf1
           server srv1 /tmp/repro-log-forward.sock

       log-forward relay
           bind unix@/tmp/repro-log-forward.sock mode 660
           log ring@buf1 local0

2. Less visibly, a ring server given a DGRAM address (e.g.
   "server s1 udp@127.0.0.1:1514") was, until now, let through the
   log-backend family check (DGRAM is not rejected there) and reaches
   connect_server() at runtime, which promptly segfaults in
   conn_select_mux_be() -> proto_is_quic() on a NULL proto, since a
   ring's forward_px only ever expects a STREAM transport. This patch
   also closes that crash, by routing rings back through the regular
   STREAM-only check that non-log backends already get.

40eb1dd13 ("BUG/MEDIUM: sink: fix unexpected double postinit of sink
backend") already gives the sink's forward_px the PR_CAP_INT capability
for a related reason (skip the automatic log-backend postinit, since
sink manages it manually). This reuses that same flag to also skip the
log-backend-specific address checks for the same class of proxies,
since they are never real user-configured log backends.

This should be backported up to 3.3, but only where 23e5f18b8 and
40eb1dd13 are backported too - without the latter (which sets
PR_CAP_INT on forward_px), this patch is a silent no-op.

src/server.c

index 8cd97b9784fe84f70f76a431b2ad9c4ef66ab688..b60be4ce32230d9c8dcd495c97ae21b77f27cb73 100644 (file)
@@ -3562,9 +3562,15 @@ static int _srv_check_proxy_mode(struct server *srv, char postparse)
                goto out;
        }
 
-       if (srv->proxy->mode == PR_MODE_SYSLOG) {
+       if (srv->proxy->mode == PR_MODE_SYSLOG && !(srv->proxy->cap & PR_CAP_INT)) {
                /* log backend server (belongs to proxy with mode log enabled):
-                * perform some compatibility checks
+                * perform some compatibility checks. Internal proxies (PR_CAP_INT,
+                * e.g. a sink's forward_px backing a "ring" section) are excluded:
+                * they are tagged PR_MODE_SYSLOG for type-awareness purposes only
+                * (see 23e5f18b8) and are not real user-configured log backends,
+                * so they may legitimately target a UNIX socket (e.g. to feed a
+                * local "log-forward" section). They still go through the regular
+                * STREAM-transport check below, in the "else" branch.
                 */
 
                /* supported address family types are: