send credentials or not?

Simon McVittie simon.mcvittie at collabora.co.uk
Tue May 29 05:42:51 PDT 2012


On 29/05/12 13:02, Martin Vidner wrote:
> how can a client of a bus tell whether it should [send the
> credentials][creds] or not?

If you know how, for that specific OS, send credentials; if you don't,
don't. The worst that'll happen by not sending credentials is that you
have to use DBUS_COOKIE_SHA1 authentication (prove that you are who you
say you are by proving that you can access that user's ~/.dbus), like
you would for TCP.

> I got a [report][21] for Ruby-DBus that it doesn't work on OpenBSD

Unfortunately, the *BSD family don't all support the same extensions, so
doing the same thing on OpenBSD as on FreeBSD (or NetBSD, or Dragonfly
BSD, etc...) is a bug in Ruby-DBus.

GIO/GDBus supports Linux, FreeBSD and OpenBSD with four separate
implementations (two of which are for Linux).

Linux: struct ucred; turn on SO_PASSCRED on receiving side and read
SO_PEERCRED, or (separate implementation) send a SCM_CREDENTIALS message
and receive it. GIO looks as though it prefers to use the
SO_PASSCRED/SO_PEERCRED version, and libdbus only supports that version.

FreeBSD: struct cmsgcred; send a SCM_CREDS message and receive it
(similar to Linux's SCM_CREDENTIALS, but with different naming). libdbus
also supports this.

OpenBSD: struct sockpeercred; read SO_PEERCRED on receiving side
(similar to Linux's, but with a different struct). libdbus also supports
this.

libdbus also supports some other things, but unfortunately does not
document which platform(s) they're for: possibly Solaris or Mac OS X?
(Mac OS X has a FreeBSD-derived kernel, but it wouldn't surprise me if
it does something different here).

* a LOCAL_CREDS socket option which transfers a struct sockcred (a bit
like SO_PEERCRED?)

* a getpeerucred() syscall returning ucred_t * (this seems to interact
with "ADT", so it's probably for Solaris)

* a getpeereid() syscall returning uid_t (like a simpler version of
getpeerucred())

I wish there was a POSIX interface for this... but at the moment we're
stuck with all these different variations.

    S


More information about the dbus mailing list