We have an application that is running inside a container that we are starting using systemd-nspawn. Note the systemd-nspawn config uses dynamic users where the process in the container believes it is root, but it is running as a non-root process from perspective of system dbus instance. We bind mount in the system's dbus socket so that we can access the System bus. This all works fine when using the 'sdbus' library from C code. When we did the exact same thing using godbus, we get an authentication error. Debugging, it comes down to 2 'main' things, but we also found 2 other issues worth reporting:

1. (main issue) sdbus C library sends "AUTH EXTERNAL\r\n", godbus sends "AUTH EXTERNAL 30\r\n"
   Inside the container, we are running as getuid() == 0 (ie. root). But we are using the systemd dynamic user to run as an actual non-root user outside the container (ie. uid 12345). Because we are telling dbus that we are UID 0 (hex 0x30) in the "AUTH EXTERNAL 30" line, dbus refuses to allow us to connect because we are actually UID 12345 (for example).

2. (main issue) dbus sends a "spurious" line of "DATA\r\n" and expects a reply of "DATA\r\n". The godbus code specifically checks for DATA lines without parameters and fails. It also falls out of the state machine with an auth error because it is expecting "OK" when the "DATA" string arrives instead.

3. (side issue) sdbus C library "pipelines" all of the initial connection details instead of doing the query and back and forth. This allows sdbus to connect much faster. (Not related to the failure, but worth a note).

4. (side issue) godbus sends SCM_CREDENTIALS with the initial null byte. This seems completely superfluous and appears to be unused by linux dbus. This doesnt cause the container authentication failure, but seems like something that probably should be removed lest it cause issues in the future. It sends SCM_CREDENTIALS saying it's UID 0, GID 0, which dbus would reject if it actually checked these.