IRC.

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,
+Inc."]]
 
 [[!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.
 
----
+[[!toc]]
 
-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
       wrong)
     <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
+      HAVE_ABSTRACT_SOCKETS What's missing?
+    <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>
+      http://lists.freebsd.org/pipermail/freebsd-hackers/2008-May/024577.html
+    <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>
+      http://stackoverflow.com/questions/10037086/so-peercred-vs-scm-credentials-why-there-are-both-of-them
+    <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/