Revert "rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn"

This reverts commit 95878586ec7611791f4001a4ee17abf943fae3c1.

1 files changed, 502 insertions, 0 deletions

diff --git a/open_issues/dbus.mdwn b/open_issues/dbus.mdwn
new file mode 100644
index 00000000..b3bebf48
--- /dev/null
+++ b/open_issues/dbus.mdwn
@@ -0,0 +1,502 @@
+[[!meta copyright="Copyright © 2011, 2012, 2013, 2014 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
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!tag open_issue_hurd]]
+
+The dbus problems are due to missing scm credentials [[sendmsg_scm_creds]] and socket credentials
+[[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
+
+    <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
+
+    <braunr> pinotree: what's the problem with dbus ?
+    <pinotree> braunr: select() returning 0 changed fd's with very short (eg <
+      1ms) timeouts when there are actually events;
+
+[[select]].
+
+    <pinotree> and missing socket credentials
+
+[[sendmsg_scm_creds]].
+
+    <braunr> oh
+    <braunr> which socket creds interface ?
+    <pinotree> bsd, i.e. with SCM_CREDENTIALS payload for cmsg on
+      {recv,send}msg()
+    <braunr> ok
+    <braunr> SCM_RIGHTS too ?
+    <braunr> the select issue seems weird though
+    <pinotree> hm no, that's for passing fd's to other processes
+    <braunr> is it specific to pflocal or does dbus use pfinet too ?
+    <pinotree> iirc on very short timeouts the application has no time waiting
+      for the reply of servers
+    <braunr> i see
+    <pinotree> braunr: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=79358
+    <braunr> thanks
+    <pinotree> (the interesting messages are from #53 and on)
+    <braunr> 2000 eh ... :)
+    <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
+
+    <braunr> hm, i don't see any occurrence of SCM_CREDENTIALS in dbus
+    <braunr> only SCM_RIGHTS
+    <pinotree> braunr: yes, that one
+    <braunr> oh
+    <braunr> i thought you said the opposite last time
+    <pinotree> dbus/dbus-sysdeps-unix.c, write_credentials_byte and
+      _dbus_read_credentials_socket (with #define HAVE_CMSGCRED)
+    <braunr> hm
+    <braunr> which version ?
+    <braunr> i don't see anything in 1.4.16
+    <pinotree> 1.4.16
+    <braunr> grmbl
+    <braunr> ah, i see
+    <braunr> SCM_CREDS
+    <pinotree> if you want, i have a simplier .c source with it
+    <braunr> no i'm just gathering info
+    <pinotree> ok
+    <braunr> what's the deal with SCM_CREDS and SCM_CREDENTIALS ?
+    <braunr> bsd vs sysv ?
+    <braunr> oh, http://lists.debian.org/debian-hurd/2002/03/msg00135.html
+    <braunr> so we actually do want both SCM_CREDS and SCM_RIGHTS for debus
+    <braunr> dbus
+    <pinotree> SCM_RIGHTS is a different matter, it is for passing fd's
+    <braunr> yes
+    <braunr> but it's used by dbus
+    <braunr> so if we can get it, it should help too
+    <pinotree> there's a preliminary patch for it done by emilio time ago, and
+      iirc it's applied to debian's glibc
+    <braunr> ah, he changed the libc
+    <braunr> right, that's the only sane way
+    <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/
+
+
+# Emails
+
+# IRC, freenode, #hurd, 2013-10-16
+
+    <braunr> gnu_srs: how could you fail to understand credentials need to be
+      checked ?
+    <gnu_srs> braunr: If data is sent via sendmsg, no problem, right?
+    <braunr> gnu_srs: that's irrelevant
+    <gnu_srs> It's just to move the check to the receive side.
+    <braunr> and that is the whole problem
+    <braunr> it's not "just" doing it
+    <braunr> first, do you know what the receive side is ?
+    <braunr> do you know what it can be ?
+    <braunr> do you know where the corresponding source code is to be found ?
+    <gnu_srs> please, describe a scenario where receiving faulty ancillary data
+      could be a problem instead
+    <braunr> dbus
+    <braunr> a user starting privileged stuff although he's not part of a
+      privileged group of users for example
+    <braunr> gnome, kde and others use dbus to pass user ids around
+    <braunr> if you can't rely on these ids being correct, you can compromise
+      the whole system
+    <braunr> because dbus runs as root and can give root privileges
+    <braunr> or maybe not root, i don't remember but a system user probably
+    <pinotree> "messagebus"
+    <gnu_srs> k!
+    <braunr> see http://www.gnu.org/software/hurd/open_issues/dbus.html
+    <braunr> IRC, freenode, #hurd, 2013-07-17
+    <braunr> <teythoon> and the proper fix is to patch pflocal to query the
+      auth server and add the credentials?
+    <braunr> <pinotree> possibly
+    <braunr> <teythoon> that doesn't sound to bad, did you give it a try?
+
+
+# IRC, freenode, #hurd, 2013-10-22
+
+    <gnu_srs> I think I have a solution on the receive side for SCM_CREDS :)
+
+    <gnu_srs> A question related to SCM_CREDS: dbus use a zero data byte to get
+      credentials sent.
+    <gnu_srs> however, kfreebsd does not care which data (and credentials) is
+      sent, they report the credentials anyway
+    <gnu_srs> should the hurd implementation do the same as kfreebsd?
+    <youpi> gnu_srs: I'm not sure to understand: what happens on linux then?
+    <youpi> does it see zero data byte as being bogus, and refuse to send the
+      creds?
+    <gnu_srs> linux is also transparent, it sends the credentials independent
+      of the data (but data has to be non-null)
+    <youpi> ok
+    <youpi> anyway, what the sending application writes does not matter indeed
+    <youpi> so we can just ignore that
+    <youpi> and have creds sent anyway
+    <braunr> i think the interface normally requires at least a byte of data
+      for ancilliary data
+    <youpi> possibly, yes
+    <braunr>        To pass file descriptors or credentials over a SOCK_STREAM,
+      you need to  send  or
+    <braunr>        receive  at  least  one  byte  of  non-ancillary  data  in
+      the same sendmsg(2) or
+    <braunr>        recvmsg(2) call.
+    <braunr> but that may simply be linux specific
+    <braunr> gnu_srs: how do you plan on implementing right checking ?
+    <gnu_srs> Yes, data has to be sent, at least one byte, I was asking about
+      e.g. sending an integer 
+    <braunr> just send a zero
+    <braunr> well
+    <braunr> dbus already does that
+    <braunr> just don't change anything
+    <braunr> let applications pass the data they want
+    <braunr> the socket interface already deals with port rights correctly
+    <braunr> what you need to do is make sure the rights received match the
+      credentials
+    <gnu_srs> The question is to special case on a zero byte, and forbid
+      anything else, or allow any data.
+    <braunr> why would you forbid 
+    <braunr> ?
+    <gnu_srs> linux and kfreebsd does not special case on a received zero byte
+    <braunr> same question, why would you want to do that ?
+    <gnu_srs> linux sends credentials data even if no SCM_CREDENTIALS structure
+      is created, kfreebsd don't
+    <braunr> i doubt that
+    <gnu_srs> To be specific:msgh.msg_control = NULL; msgh.msg_controllen = 0;
+    <braunr> bbl
+    <gnu_srs> see the test code:
+      http://lists.debian.org/debian-hurd/2013/08/msg00091.html
+    <braunr> back
+    <braunr> why would the hurd include groups when sending a zero byte, but
+      only uid when not ?
+    <gnu_srs> ?
+    <braunr> 1) Sent credentials are correct:
+    <braunr> no flags: Hurd: OK, only sent ids
+    <braunr> -z Hurd: OK, sent IDs + groups
+    <braunr> and how can it send more than one uid and gid ?
+    <braunr> "sent credentials are not honoured, received ones are created"
+    <gnu_srs> Sorry, the implementation is changed by now. And I don't special
+      case on a zero byte.
+    <braunr> what does this mean ?
+    <braunr> then why give me that link ?
+    <gnu_srs> The code still applies for Linux and kFreeBSD. 
+    <gnu_srs> It means that whatever you send, the kernel emits does not read
+      that data: see
+    <gnu_srs> socket.h: before  struct cmsgcred: the sender's structure is
+      ignored ...
+    <braunr> do you mean receiving on a socket can succeed with gaining
+      credentials, although the sender sent wrong ones ?
+    <gnu_srs> Looks like it. I don't have a kfreebsd image available right now.
+    <gnu_srs> linux returns EPERM
+    <braunr> anyway
+    <braunr> how do you plan to implement credential checking ?
+    <gnu_srs> I'll mail patches RSN
+
+
+# IRC, freenode, #hurd, 2013-11-03
+
+    <gnu_srs> Finally, SCM_CREDS (IDs) works:) I was on the right track all the
+      time, it was just a small misunderstanding.
+    <gnu_srs> remains to solve the PID check
+    <youpi> gnu_srs: it should be a matter of adding
+      proc_user/server_authenticate
+    <gnu_srs> there are no proc_user/server_authenticate RPCs?
+    <gnu_srs> do you mean adding them to process.defs (and implement them)?
+    <youpi> gnu_srs: I mean that, yes
+
+
+# IRC, freenode, #hurd, 2013-11-13
+
+    <gnu_srs> BTW: I have to modify the SCM_RIGHTS patch to work together with
+      SCM_CREDS, OK?
+    <youpi> probably
+    <youpi> depends on what you change of course
+
+
+# IRC, freenode, #hurd, 2013-11-15
+
+    <gnu_srs> Hi, any ideas where this originates, gdb? warning: Error setting
+      exception port for process 9070: (ipc/send) invalid destination port
+    <braunr> gnu_srs: what's process 9070 ?
+    <gnu_srs> braunr: It's a test program for sending credentials over a
+      socket. Have to create a reproducible case, it's intermittent.
+    <gnu_srs> The error happens when running through gdb and the sending
+      program is chrooted:
+    <gnu_srs> -rwsr-sr-x 1 root root 21156 Nov 15 15:12
+      scm_rights+creds_send.chroot
+
+
+## IRC, freenode, #hurd, 2013-11-16
+
+    <gnu_srs> Hi, I have a problem debugging a suid program, see
+      http://paste.debian.net/66171/
+    <gnu_srs> I think this reveals a gnumach/hurd bug, it makes things behave
+      strangely for other programs.
+    <gnu_srs> How to get further on with this?
+    <gnu_srs> Or can't I debug a suid program as non-root?
+    <pochu> gnu_srs: if gdb doesn't work for setuid programs on hurd, I suppose
+      you could chmod -s the binary you're trying to debug, login as root and
+      run it under gdb
+    <gnu_srs> pochu: When logged in as root the program works, independent of
+      the s flag setting.
+    <pochu> right, probably the setuid has no effect in that case because your
+      effective uid is already fine
+    <pochu> so you don't hit the gdb bug in that case
+    <pochu> (just guessing)
+    <gnu_srs> It doesn't work in Linux either, so it might be futile.
+    <gnu_srs> trying
+    <pochu> hmm that may be the expected behaviour. after all, gdb needs to be
+      priviledged to debug priviledged processes
+    <gnu_srs> Problem is that it was just the suid properties I wanted to
+      test:(
+    <braunr> gnu_srs: imagine if you could just alter the code or data of any
+      suid program just because you're debugging it
+
+
+## IRC, freenode, #hurd, 2013-11-18
+
+    <gnu_srs> Hi, is the code path different for a suid program compared to run
+      as root?
+    <gnu_srs> Combined with LD_PRELOAD?
+    <teythoon> gnu_srs: afaik LD_PRELOAD is ignored by suid programs for
+      obvious security reasons
+    <gnu_srs> aha, thanks:-/
+    <braunr> gnu_srs: what's your problem with suid ?
+    <gnu_srs> I made changes to libc and tried them out with
+      LD_PRELOAD=... test_progam. It worked as any user (including root),
+    <gnu_srs> but not with suid settings. Justus explained why not.
+    <braunr> well i did too
+    <braunr> but is that all ?
+    <braunr> i mean, why did you test with suid programs in the first place ?
+    <gnu_srs> to get different euid and egid numbers
+
+    <gnu_srs> hi, anybody seen this with eglibc-2.17-96: locale: relocation
+      error: locale: symbol errno,
+    <gnu_srs> version GLIBC_PRIVATE not defined in file libc.so.0.3 with link
+      time reference
+    <teythoon> yes, I have
+    <teythoon> but afaics nothing did break, so I ignored it
+
+
+## IRC, freenode, #hurd, 2013-11-23
+
+    <gnu_srs> Finally 8-)
+    <gnu_srs> Good news: soon both SCM_CREDS _and_ SCM_RIGHTS is supported
+      jointly. RFCs will be sent soon.
+
+
+## IRC, freenode, #hurd, 2013-12-05
+
+    <gnu_srs> I have a problem with the SCM_CREDS patch and dbus. gamin and my
+      test code runs fine.
+    <gnu_srs> the problem with the dbus code is that it won't work well with 
+    <gnu_srs> auth_user_authenticate in sendmsg and auth_server_authenticate in
+      recvmsg.
+    <gnu_srs> Should I try to modify the dbus code to make it work?
+    <youpi> unless you manage to prove that dbus is not following the posix
+      standard, there is no reason why you should have to modify dbus
+    <gnu_srs> I think the implementation is correct,
+    <gnu_srs> but auth_user_authenticate hangs sendmsg until
+      auth_seerver_authenticate is executed in recvmsg.
+    <gnu_srs> and dbus is not doing that, so it hangs in sendmsg writing a
+      credentials byte.
+    <gnu_srs> well the credentials byte is definitely non-posix.
+    <gnu_srs> I found a bug related to the HURD_DPORT_USE macro too:-(
+    <youpi> ah, yes, auth_user_authenticate might be synchronous indeed, let me
+      think about it
+    <gnu_srs> Nevertheless, I think it's time to publish the code so it can be
+      commented on:-D
+    <youpi> sure
+    <youpi> publish early, publish often
+
+
+# IRC, freenode, #hurd, 2014-01-17
+
+    <gnu_srs> youpi: as a start all our requested dbus changes are now
+      committed, and in Debian unstable
+    <youpi> good :)
+
+
+# IRC, freenode, #hurd, 2014-01-30
+
+    <pochu> dbus has some known problems
+    <pere> known fixes too?
+    <pochu> http://www.gnu.org/software/hurd/open_issues/dbus.html
+    <gnu_srs> pochu: Maybe that page should be updated:
+      http://lists.nongnu.org/archive/html/bug-hurd/2013-12/msg00150.html
+    <youpi> gnu_srs: well, maybe you can do it :
+    <youpi> )