sd-bus: allow cross-uid-namespace connections #11785
This PR allows
The first patch fixes a bug in the sd-bus server SASL implementation.
The second patch improves sd-bus to no longer send uids verbatim. Instead, we send an empty argument to
Note that this PR will very likely break live-updates. The problem is that sd-bus currently is broken since it sends incorrect SASL lines as server. So if you merge this PR and run
hmm, not sure i follow. i mean, the new behaviour is triggered by the client, no? i.e. old clients send the auth token along with the AUTH iiuc, and the server replies to that with a correct answer. new clients with your patch applied will send no auth token and instead expect a DATA reply, iiuc. hence, why not update the clients to that it can also deal with the missing DATA reply in that case? unless i am missing something this should make all clients work against all servers, no? because for old clients the server response on old and new is not differnt, and for new clients we can just make sure that both types of server responses (the old incorrect + the new correct) is accepted, no?
Yes, we can make clients accept the "incorrect" response, but that will mean we accept weird server behavior. To be clear, we would then allow a server to respond with one of these:
Problem is, a non-pipelining client would actually not respond with "DATA " to a line that says "OK", but the broken server does require the client to respond with "DATA ".
So yeah, we can make the client accept both without causing any bigger issues other than possibly being unable to catch issues in other implementations (which I agree is probably negligible).
This also seems to break something fundamental, as the failed test log shows:
These three "access denied" are from trying to stop three services (
This reproduces perfectly locally, so this is a real regression indeed.
The correct way to reply to "AUTH <protocol>" without any payload is to send "DATA" rather than "OK". The "DATA" reply triggers the client to respond with the requested payload. In fact, adding the data as hex-encoded argument like "AUTH <protocol> <hex-data>" is an optimization that skips the "DATA" roundtrip. The standard way to perform an authentication is to send the "DATA" line. This commit fixes sd-bus to properly send the "DATA" line. Surprisingly no existing implementation depends on this, as they all pass the data directly as argument to "AUTH". This will not work if we want to pass an empty argument, though. Signed-off-by: David Rheinsberg <email@example.com>
The dbus external authentication takes as optional argument the UID the sender wants to authenticate as. This uid is purely optional. The AF_UNIX socket already conveys the same information through the auxiliary socket data, so we really don't have to provide that information. Unfortunately, there is no way to send empty arguments, since they are interpreted as "missing argument", which has a different meaning. The SASL negotiation thus changes from: AUTH EXTERNAL <uid> NEGOTIATE_UNIX_FD (optional) BEGIN to: AUTH EXTERNAL DATA NEGOTIATE_UNIX_FD (optional) BEGIN And thus the replies we expect as a client change from: OK <server-id> AGREE_UNIX_FD (optional) to: DATA OK <server-id> AGREE_UNIX_FD (optional) Since the old sd-bus server implementation used the wrong reply for "AUTH" requests that do not carry the arguments inlined, we decided to make sd-bus clients accept this as well. Hence, sd-bus now allows "OK <server-id>\r\n" replies instead of "DATA\r\n" replies. Signed-off-by: David Rheinsberg <firstname.lastname@example.org>