Enabling mod_privilege prevents component from sending un-privileged IQ

[mtstickney]

Environment

• ejabberd version: 24.12
• Erlang version: Erlang (SMP,ASYNC_THREADS) (BEAM) emulator version 15.1.3
• OS: Linux (Arch Linux)
• Installed from: distro package

Configuration (only if needed):

listen:
  -
    port: 5101
    ip: "127.0.0.1"
    module: ejabberd_service
    hosts:
      matridge.aptnet.home.arpa:
        password: <secret>
acl:
  slidge_gateways:
    - server: "matridge.aptnet.home.arpa"
access_rules:
  slidge_gateways_rule:
    allow: slidge_gateways
modules:
  mod_privilege:
    roster:
      both: slidge_gateways_rule

Errors from error.log/crash.log

2025-01-11 01:22:53.438 [info] (#PID<0.703.0>) Accepted connection 127.0.0.1:55922 -> 127.0.0.1:5101
2025-01-11 01:22:53.442 [info] (tcp|<0.703.0>) Accepted external component handshake authentication for matridge.aptnet.home.arpa from 127.0.0.1
2025-01-11 01:22:53.444 [info] Granting permissions to external component 'matridge.aptnet.home.arpa': roster = both, presence = none, message = none,
iq = []
2025-01-11 01:22:55.449 [info] IQ not forwarded: Component tried to send not wrapped IQ stanza.

Bug description

(This is behavior observed with matridge, a slidge-based transport, but I've also replicated it with my own simpler script using the XEP-0114 handshake, because I didn't want to try to figure out how to hack up SASL and the like. I'm not completely sure what component protocol slidge uses (XEP-0225? XEP-0114? something else?), but hopefully the differences won't matter.)

If ejabberd is configured with mod_privilege enabled, even if it is only granting non-IQ permissions like outgoing message support or roster privileges, the server declines to forward non-privileged IQ stanzas, complaining that it is non-wrapped (see logs above). Enabling mod_privilege seems to require components to only send privileged IQs, and prevents them from sending any IQ packet on their own behalf.

An example stanza that triggers the log message:

<iq type="get" to="[email protected]" from="matridge.aptnet.home.arpa"
        id="b212a556567e4a53aa42b5ca9658e9d5">
  <pubsub xmlns="http://jabber.org/protocol/pubsub">
    <items node="urn:xmpp:avatar:metadata" />
  </pubsub>
</iq>

As best I can tell, this is a bug: if mod_privilege is not enabled, the server doesn't complain about forwarding non-privileged IQs -- I can't prove they're actually processed usefully, but I don't see any evidence they aren't. Since components seem to be permitted to send IQs on their own behalf when mod_privilege is disabled, I'd expect them to continue to be able to do so when they've been granted extra privileges (but I'm not an XMPP expert, so maybe I've got some part of this wrong).