path: root/open_issues/dbus.mdwn
diff options
authorThomas Schwinge <>2013-09-25 21:45:38 +0200
committerThomas Schwinge <>2013-09-25 21:45:38 +0200
commiteccdd13dd3c812b8f0b3d046ef9d8738df00562a (patch)
treee6c585035d2e869e26a0d3a93efa51810543d40e /open_issues/dbus.mdwn
parent9933cec0a18ae2a3d752f269d1bb12c19f51199d (diff)
Diffstat (limited to 'open_issues/dbus.mdwn')
1 files changed, 170 insertions, 5 deletions
diff --git a/open_issues/dbus.mdwn b/open_issues/dbus.mdwn
index 2f02579e..a41515a1 100644
--- a/open_issues/dbus.mdwn
+++ b/open_issues/dbus.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2012, 2013 Free Software Foundation,
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -14,15 +15,17 @@ The dbus problems are due to missing scm credentials [[sendmsg_scm_creds]] and s
[[pflocal_socket_credentials_for_local_sockets]]. There was also a problem with short timeout in
[[select]], but that has been solved in Debian by setting a minimum timeout of 1ms.
-IRC, freenode, #hurd, 2011-11-26:
+# IRC, freenode, #hurd, 2011-11-26
<antrik> BTW, how much effort is necessary to fix dbus?
<pinotree> basically, have pflocal know who's the sender
(pid/uid/gid/groups) in the socket send op
-IRC, freenode, #hurd, 2011-12-16:
+# IRC, freenode, #hurd, 2011-12-16
<braunr> pinotree: what's the problem with dbus ?
<pinotree> braunr: select() returning 0 changed fd's with very short (eg <
@@ -53,7 +56,8 @@ IRC, freenode, #hurd, 2011-12-16:
<braunr> hm i agree with neal, i don't understand why the timeout is given
to the kernel as part of the mach_msg call
-IRC, freenode, #hurd, 2011-12-20:
+# IRC, freenode, #hurd, 2011-12-20
<braunr> hm, i don't see any occurrence of SCM_CREDENTIALS in dbus
<braunr> only SCM_RIGHTS
@@ -88,3 +92,164 @@ IRC, freenode, #hurd, 2011-12-20:
<pinotree> iirc roland didn't like one or more parts of it (but i could be
<braunr> ok
+# IRC, freenode, #hurd, 2013-07-17
+ <teythoon> btw pinotree, what happened to your efforts to make dbus work?
+ <pinotree> not much, my initial patch was just a crude hack, a better
+ solution requires more thinkering and work
+ <teythoon> yes, ive seen that
+ <teythoon> but that was only a tiny patch against the libc, surely there
+ must be more to that?
+ <pinotree> not really
+ <teythoon> and the proper fix is to patch pflocal to query the auth server
+ and add the credentials?
+ <pinotree> possibly
+ <teythoon> that doesn't sound to bad, did you give it a try?
+ <pinotree> not really, got caught in other stuff
+# IRC, freenode, #hurd, 2013-09-02
+ <gnu_srs1> something is wrong with libc0.3 since the switch to 2.17. dbus
+ does not run any longer when rebuilt
+ <gnu_srs1> the latest build of dbus was with 2.13: libc0.3-dev: already
+ installed (2.13-38)
+ <pinotree> debug it
+ <gnu_srs1> Yes, I will. Maybe somebody could rebuild it and verify my
+ findings?
+ <pinotree> gnu_srs1: your finding is "doesn't work", which is generic and
+ does not help without investigation
+ <gnu_srs1> just rebuild it and: e.g. ./build-debug/bus/dbus-daemon --system
+ (--nofork)
+ <pinotree> gnu_srs1: please, debug it
+ <gnu_srs1> I have partially already. But maybe the problems only shows on
+ my box. I'll rebuild on another box before continuing debugging.
+ <pinotree> gnu_srs1: are you, by chance, running a libc or something else
+ with your scm_creds work?
+ <gnu_srs1> I did, but I've backed to 2.17-92 right now.
+ <gnu_srs1> sane problem with dbus on another box, something's fishy:-(
+ <gnu_srs1> braunr: any good way to find out if the dbus problems are with
+ libpthread? Setting a breakpoint with libc0.3-dbg installed.
+ <braunr> gnu_srs1: i don't know
+See [[glibc]], *Missing interfaces, amongst many more*, *`SOCK_CLOEXEC`*.
+# IRC, freenode, #hurd, 2013-09-04
+ <gnu_srs> Hi, looks like dbus requires abstract socket namespace: #undef
+ <pinotree> uh?
+ <pinotree> abstract unix sockets are a Linux feature, and surely it is not
+ mandatory for dbus
+ <gnu_srs> Looks like dbus exits if they are not supported:
+ <gnu_srs> dbus_set_error (error, DBUS_ERROR_NOT_SUPPORTED, "Operating
+ system does not support abstract socket namespace\n");   _dbus_close
+ (listen_fd, NULL); 1061  return -1;
+ <pinotree> that is enclosed in a if (abstract)
+ <pinotree> and that parameter is set to true in other places (eg
+ dbus/dbus-server-unix.c) only when HAVE_ABSTRACT_SOCKETS is defined
+ <pinotree> so no, abstract sockets are not mandatory
+ <gnu_srs> Well this code is executed e.g. when running emacs remotely in
+ X. Have to dig deeper then to see why.
+ <pinotree> maybe it could have to do the fact that your dbus server is
+ running in linux and runs by default using such sockets type
+ <pinotree> but yes, you need to dig better
+ <gnu_srs> pinotree: You are right. when running natively the problem is:
+ <pinotree> *drums*
+ <gnu_srs> Manually: Process /usr/lib/at-spi2-core/at-spi-bus-launcher
+ exited with status 1
+ <pinotree> eh?
+ <gnu_srs> Error retrieving accessibility bus address:
+ org.freedesktop.DBus.Error.Spawn.ChildExited: ^
+ <pinotree> most probably that service does not start due to the lack of
+ socket credentials which affects dbus
+ <pinotree> uninstall or disable those additional services, they are not
+ your problem
+ <gnu_srs> credentials is enabled. which services to remove?
+ <pinotree> dunno
+# IRC, freenode, #hurd, 2013-09-11
+ <gnu_srs> Hi, looks like frebsd had (2008) the same problem as hurd when
+ sending credentials over PF_INET:
+ <gnu_srs>
+ <gnu_srs> Since the dbus code is about the same now (2013), maybe they
+ added support?
+ <gnu_srs> The next message in the thread confirms that the dbus code is
+ invalid, does anybody have pointers?
+ <pinotree> from what i've seen so far, socket credentials are done only for
+ local sockets (ie PF_UNIX)
+ <pinotree> i don't see how things like uid/gid/pid of the socket endpoint
+ can have anything to do with AF_INET
+ <pinotree> and socket credentials in dbus are used only in the [local]
+ socket transport, so there's no issue
+# IRC, freenode, #hurd, 2013-09-12
+ <gnu_srs> pinotree: Yes, there is an issue with dbus and AF_INET, see
+ test/corrupt.c: tests /corrupt/tcp and /corrupt/byte-order/tcp:-/
+ <pinotree> gnu_srs: what's wrong with those? they are just testing the
+ connection over a tcp socket
+ <pinotree> as said above, socket credentials shouldn't be used in such
+ cases
+ <gnu_srs> They are, see also test/relay.c: /relay and /limit tests:-(
+ <pinotree> how are they?
+ <pinotree> please be more specifc...
+ <gnu_srs> Just run the tests yourself with DBUS_VERBOSE=1
+ <pinotree> you are claiming there is a problem, so please specify what is
+ the actual issue
+ <gnu_srs> DBUS_VERBOSE=1 build-debug/test/test-relay
+ <pinotree> you are claiming there is a problem, so please specify what is
+ the actual issue
+ <gnu_srs> same with test-corrupt
+ <gnu_srs> look at the verbose output: Failed to write credentials: Failed
+ to write credentials byte: Invalid argument
+ <gnu_srs> coming from pfinet since PF_INET is used.
+ <pinotree> check what it does on linux then
+ <pinotree> put an abort() at the start of the read/write socket credential
+ functions in dbus-sysdeps-unix.c and see whether it is triggered also on
+ linux
+ <gnu_srs> SO_PEERCRED is used for linux and LOCAL_CREDS is used for
+ kfreebsd, so we are on our own here:-/
+ <pinotree> and linux' SO_PEERCRED works also on AF_INET sockets? i'd doubt
+ it
+ <gnu_srs>
+ <pinotree> yes, i know the difference, but please read what i asked again
+ <gnu_srs> I'll check to be sure...
+ <braunr> gnu_srs: user credentials are not supposed to be passed through an
+ AF_INET socket
+ <braunr> how hard is that to understand ?
+ <gnu_srs> OK, linux use send since CMSGCREDS is not defined to write
+ credentials. Working on how they are received.
+ <gnu_srs> braunr: I do understand, but the dbus code tries to do that for
+ Hurd:-(
+ <pinotree> then it should do that on linux too
+ <pinotree> (since the local socket credentials code is isolated in own
+ functions, and they are called only for the unix transport)
+ <gnu_srs> Happiness:-D, almost all dbus tests pass!
+ <gnu_srs> 17(17) dbus tests pass:)
+ <braunr> gnu_srs: hopefully your patch does things right
+ <gnu_srs> which patch
+ <braunr> adding credentials through unix socket
+ <braunr> isn't that what you're doing ?
+ <gnu_srs> the mail to MLs is from the stock installed packages.
+ <braunr> ?
+ <gnu_srs> the test reports are with the SCM_CREDS patches, but I stumbled
+ on the SCM_RIGHTS issues reported to MLs
+ <gnu_srs> no patches applied, just test the attached file yourself.
+ <braunr> so what's your work about ?
+ <gnu_srs> I'm working on SCM_CREDS, yes, and created patches for dbus,
+ glib2.0 and libc.
+ <gnu_srs> the mail was about some bug in the call to io_restrict_auth in
+ sendmsg.c: without any of my patches applied (another image)
+ <teythoon> gnu_srs: you have to give us more context, how are we supposed
+ to know how to find this sendmsg.c file?
+ <pinotree> (it's in glibc, but otherwise the remark is valid)
+ <pinotree> s/otherwise/anyway/