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