[Bug 28366] Add DBusTube interface support

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Fri Nov 11 12:06:37 CET 2011


https://bugs.freedesktop.org/show_bug.cgi?id=28366

--- Comment #23 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2011-11-11 03:06:37 PST ---
(In reply to comment #21)
> Btw, on the subject of credential checking - did you verify that it makes sense
> for the API user to decide whether the SCM_CREDS message should be required?

The D-Bus wire protocol always has one '\0' byte at the very beginning of the
stream, which is not part of the authentication handshake (text-based SASL) and
also not part of any of the subsequent D-Bus messages (binary). libdbus, GDBus
etc. assume that this byte will always be present.

If credentials-passing via SCM_CREDS (FreeBSD) or SCM_CREDENTIALS (Linux) is
supported, the credentials accompany that '\0' byte.

If the platform can't pass credentials (Windows) or can pass/get credentials
without sending a byte (Linux and OpenBSD via SO_PEERCRED, some other platforms
(Solaris?) via getpeereid or getpeerucred), it must still send the '\0' byte.

On OSs where you can choose whether to send credentials out-of-band
(LOCAL_CREDS - I don't know which platforms actually have this?), D-Bus expects
you to say "yes" to LOCAL_CREDS too.

Basically, you always send '\0' accompanied by as much out-of-band information
as possible (which might be none, e.g. on Windows).

> 1) dbus unix socket transport might always require the message on platforms
> where it is supported(!!) - or is it gabble which gets to decide whether it
> requires it or not?

I don't think all Socket_Access_Control values really fit on a (new-style)
D-Bus tube - we wrote the wording for stream tubes, so they'll need
re-purposing for D-Bus tubes. DBusTube is under-specified, basically.

D-Bus connections always start with a '\0' with semantics similar to the
Socket_Access_Control_Credentials byte - that's exactly where I got the idea
for S_A_C_C from.

I think the values for S_A_C that make sense for D-Bus tubes are:

* Localhost: any local user can connect to the CM. I'd re-interpret this as
  "use dbus_connection_set_unix_user_function() and
  dbus_connection_set_windows_user_function() to set a function that
  allows everyone".

* Credentials: for D-Bus I'd either re-interpret this as
  "use the default D-Bus auth handshake as used for the session bus,
  which only allows the same uid; omit the extra byte", or deprecate it
  for D-Bus tubes (it's fine to use on stream tubes) and introduce a
  new S_A_C_DBus_Same_User which is explicitly "use the normal D-Bus
  mechanisms to determine that it's the same user".

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.



More information about the telepathy-bugs mailing list