[[!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 BTW, how much effort is necessary to fix dbus? basically, have pflocal know who's the sender (pid/uid/gid/groups) in the socket send op # IRC, freenode, #hurd, 2011-12-16 pinotree: what's the problem with dbus ? braunr: select() returning 0 changed fd's with very short (eg < 1ms) timeouts when there are actually events; [[select]]. and missing socket credentials [[sendmsg_scm_creds]]. oh which socket creds interface ? bsd, i.e. with SCM_CREDENTIALS payload for cmsg on {recv,send}msg() ok SCM_RIGHTS too ? the select issue seems weird though hm no, that's for passing fd's to other processes is it specific to pflocal or does dbus use pfinet too ? iirc on very short timeouts the application has no time waiting for the reply of servers i see braunr: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=79358 thanks (the interesting messages are from #53 and on) 2000 eh ... :) 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 hm, i don't see any occurrence of SCM_CREDENTIALS in dbus only SCM_RIGHTS braunr: yes, that one oh i thought you said the opposite last time dbus/dbus-sysdeps-unix.c, write_credentials_byte and _dbus_read_credentials_socket (with #define HAVE_CMSGCRED) hm which version ? i don't see anything in 1.4.16 1.4.16 grmbl ah, i see SCM_CREDS if you want, i have a simplier .c source with it no i'm just gathering info ok what's the deal with SCM_CREDS and SCM_CREDENTIALS ? bsd vs sysv ? oh, http://lists.debian.org/debian-hurd/2002/03/msg00135.html so we actually do want both SCM_CREDS and SCM_RIGHTS for debus dbus SCM_RIGHTS is a different matter, it is for passing fd's yes but it's used by dbus so if we can get it, it should help too there's a preliminary patch for it done by emilio time ago, and iirc it's applied to debian's glibc ah, he changed the libc right, that's the only sane way iirc roland didn't like one or more parts of it (but i could be wrong) ok # IRC, freenode, #hurd, 2013-07-17 btw pinotree, what happened to your efforts to make dbus work? not much, my initial patch was just a crude hack, a better solution requires more thinkering and work yes, ive seen that but that was only a tiny patch against the libc, surely there must be more to that? not really and the proper fix is to patch pflocal to query the auth server and add the credentials? possibly that doesn't sound to bad, did you give it a try? not really, got caught in other stuff # IRC, freenode, #hurd, 2013-09-02 something is wrong with libc0.3 since the switch to 2.17. dbus does not run any longer when rebuilt the latest build of dbus was with 2.13: libc0.3-dev: already installed (2.13-38) debug it Yes, I will. Maybe somebody could rebuild it and verify my findings? gnu_srs1: your finding is "doesn't work", which is generic and does not help without investigation just rebuild it and: e.g. ./build-debug/bus/dbus-daemon --system (--nofork) gnu_srs1: please, debug it I have partially already. But maybe the problems only shows on my box. I'll rebuild on another box before continuing debugging. gnu_srs1: are you, by chance, running a libc or something else with your scm_creds work? I did, but I've backed to 2.17-92 right now. sane problem with dbus on another box, something's fishy:-( braunr: any good way to find out if the dbus problems are with libpthread? Setting a breakpoint with libc0.3-dbg installed. gnu_srs1: i don't know See [[glibc]], *Missing interfaces, amongst many more*, *`SOCK_CLOEXEC`*. # IRC, freenode, #hurd, 2013-09-04 Hi, looks like dbus requires abstract socket namespace: #undef HAVE_ABSTRACT_SOCKETS What's missing? uh? abstract unix sockets are a Linux feature, and surely it is not mandatory for dbus Looks like dbus exits if they are not supported: 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; that is enclosed in a if (abstract) and that parameter is set to true in other places (eg dbus/dbus-server-unix.c) only when HAVE_ABSTRACT_SOCKETS is defined so no, abstract sockets are not mandatory Well this code is executed e.g. when running emacs remotely in X. Have to dig deeper then to see why. maybe it could have to do the fact that your dbus server is running in linux and runs by default using such sockets type but yes, you need to dig better pinotree: You are right. when running natively the problem is: *drums* Manually: Process /usr/lib/at-spi2-core/at-spi-bus-launcher exited with status 1 eh? Error retrieving accessibility bus address: org.freedesktop.DBus.Error.Spawn.ChildExited: ^ most probably that service does not start due to the lack of socket credentials which affects dbus uninstall or disable those additional services, they are not your problem credentials is enabled. which services to remove? dunno # IRC, freenode, #hurd, 2013-09-11 Hi, looks like frebsd had (2008) the same problem as hurd when sending credentials over PF_INET: http://lists.freebsd.org/pipermail/freebsd-hackers/2008-May/024577.html Since the dbus code is about the same now (2013), maybe they added support? The next message in the thread confirms that the dbus code is invalid, does anybody have pointers? from what i've seen so far, socket credentials are done only for local sockets (ie PF_UNIX) i don't see how things like uid/gid/pid of the socket endpoint can have anything to do with AF_INET and socket credentials in dbus are used only in the [local] socket transport, so there's no issue # IRC, freenode, #hurd, 2013-09-12 pinotree: Yes, there is an issue with dbus and AF_INET, see test/corrupt.c: tests /corrupt/tcp and /corrupt/byte-order/tcp:-/ gnu_srs: what's wrong with those? they are just testing the connection over a tcp socket as said above, socket credentials shouldn't be used in such cases They are, see also test/relay.c: /relay and /limit tests:-( how are they? please be more specifc... Just run the tests yourself with DBUS_VERBOSE=1 you are claiming there is a problem, so please specify what is the actual issue DBUS_VERBOSE=1 build-debug/test/test-relay you are claiming there is a problem, so please specify what is the actual issue same with test-corrupt look at the verbose output: Failed to write credentials: Failed to write credentials byte: Invalid argument coming from pfinet since PF_INET is used. check what it does on linux then 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 SO_PEERCRED is used for linux and LOCAL_CREDS is used for kfreebsd, so we are on our own here:-/ and linux' SO_PEERCRED works also on AF_INET sockets? i'd doubt it http://stackoverflow.com/questions/10037086/so-peercred-vs-scm-credentials-why-there-are-both-of-them yes, i know the difference, but please read what i asked again I'll check to be sure... gnu_srs: user credentials are not supposed to be passed through an AF_INET socket how hard is that to understand ? OK, linux use send since CMSGCREDS is not defined to write credentials. Working on how they are received. braunr: I do understand, but the dbus code tries to do that for Hurd:-( then it should do that on linux too (since the local socket credentials code is isolated in own functions, and they are called only for the unix transport) Happiness:-D, almost all dbus tests pass! 17(17) dbus tests pass:) gnu_srs: hopefully your patch does things right which patch adding credentials through unix socket isn't that what you're doing ? the mail to MLs is from the stock installed packages. ? the test reports are with the SCM_CREDS patches, but I stumbled on the SCM_RIGHTS issues reported to MLs no patches applied, just test the attached file yourself. so what's your work about ? I'm working on SCM_CREDS, yes, and created patches for dbus, glib2.0 and libc. the mail was about some bug in the call to io_restrict_auth in sendmsg.c: without any of my patches applied (another image) gnu_srs: you have to give us more context, how are we supposed to know how to find this sendmsg.c file? (it's in glibc, but otherwise the remark is valid) s/otherwise/anyway/ # Emails # IRC, freenode, #hurd, 2013-10-16 gnu_srs: how could you fail to understand credentials need to be checked ? braunr: If data is sent via sendmsg, no problem, right? gnu_srs: that's irrelevant It's just to move the check to the receive side. and that is the whole problem it's not "just" doing it first, do you know what the receive side is ? do you know what it can be ? do you know where the corresponding source code is to be found ? please, describe a scenario where receiving faulty ancillary data could be a problem instead dbus a user starting privileged stuff although he's not part of a privileged group of users for example gnome, kde and others use dbus to pass user ids around if you can't rely on these ids being correct, you can compromise the whole system because dbus runs as root and can give root privileges or maybe not root, i don't remember but a system user probably "messagebus" k! see http://www.gnu.org/software/hurd/open_issues/dbus.html IRC, freenode, #hurd, 2013-07-17 and the proper fix is to patch pflocal to query the auth server and add the credentials? possibly that doesn't sound to bad, did you give it a try? # IRC, freenode, #hurd, 2013-10-22 I think I have a solution on the receive side for SCM_CREDS :) A question related to SCM_CREDS: dbus use a zero data byte to get credentials sent. however, kfreebsd does not care which data (and credentials) is sent, they report the credentials anyway should the hurd implementation do the same as kfreebsd? gnu_srs: I'm not sure to understand: what happens on linux then? does it see zero data byte as being bogus, and refuse to send the creds? linux is also transparent, it sends the credentials independent of the data (but data has to be non-null) ok anyway, what the sending application writes does not matter indeed so we can just ignore that and have creds sent anyway i think the interface normally requires at least a byte of data for ancilliary data possibly, yes To pass file descriptors or credentials over a SOCK_STREAM, you need to send or receive at least one byte of non-ancillary data in the same sendmsg(2) or recvmsg(2) call. but that may simply be linux specific gnu_srs: how do you plan on implementing right checking ? Yes, data has to be sent, at least one byte, I was asking about e.g. sending an integer just send a zero well dbus already does that just don't change anything let applications pass the data they want the socket interface already deals with port rights correctly what you need to do is make sure the rights received match the credentials The question is to special case on a zero byte, and forbid anything else, or allow any data. why would you forbid ? linux and kfreebsd does not special case on a received zero byte same question, why would you want to do that ? linux sends credentials data even if no SCM_CREDENTIALS structure is created, kfreebsd don't i doubt that To be specific:msgh.msg_control = NULL; msgh.msg_controllen = 0; bbl see the test code: http://lists.debian.org/debian-hurd/2013/08/msg00091.html back why would the hurd include groups when sending a zero byte, but only uid when not ? ? 1) Sent credentials are correct: no flags: Hurd: OK, only sent ids -z Hurd: OK, sent IDs + groups and how can it send more than one uid and gid ? "sent credentials are not honoured, received ones are created" Sorry, the implementation is changed by now. And I don't special case on a zero byte. what does this mean ? then why give me that link ? The code still applies for Linux and kFreeBSD. It means that whatever you send, the kernel emits does not read that data: see socket.h: before struct cmsgcred: the sender's structure is ignored ... do you mean receiving on a socket can succeed with gaining credentials, although the sender sent wrong ones ? Looks like it. I don't have a kfreebsd image available right now. linux returns EPERM anyway how do you plan to implement credential checking ? I'll mail patches RSN # IRC, freenode, #hurd, 2013-11-03 Finally, SCM_CREDS (IDs) works:) I was on the right track all the time, it was just a small misunderstanding. remains to solve the PID check gnu_srs: it should be a matter of adding proc_user/server_authenticate there are no proc_user/server_authenticate RPCs? do you mean adding them to process.defs (and implement them)? gnu_srs: I mean that, yes # IRC, freenode, #hurd, 2013-11-13 BTW: I have to modify the SCM_RIGHTS patch to work together with SCM_CREDS, OK? probably depends on what you change of course # IRC, freenode, #hurd, 2013-11-15 Hi, any ideas where this originates, gdb? warning: Error setting exception port for process 9070: (ipc/send) invalid destination port gnu_srs: what's process 9070 ? braunr: It's a test program for sending credentials over a socket. Have to create a reproducible case, it's intermittent. The error happens when running through gdb and the sending program is chrooted: -rwsr-sr-x 1 root root 21156 Nov 15 15:12 scm_rights+creds_send.chroot ## IRC, freenode, #hurd, 2013-11-16 Hi, I have a problem debugging a suid program, see http://paste.debian.net/66171/ I think this reveals a gnumach/hurd bug, it makes things behave strangely for other programs. How to get further on with this? Or can't I debug a suid program as non-root? 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 pochu: When logged in as root the program works, independent of the s flag setting. right, probably the setuid has no effect in that case because your effective uid is already fine so you don't hit the gdb bug in that case (just guessing) It doesn't work in Linux either, so it might be futile. trying hmm that may be the expected behaviour. after all, gdb needs to be priviledged to debug priviledged processes Problem is that it was just the suid properties I wanted to test:( 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 Hi, is the code path different for a suid program compared to run as root? Combined with LD_PRELOAD? gnu_srs: afaik LD_PRELOAD is ignored by suid programs for obvious security reasons aha, thanks:-/ gnu_srs: what's your problem with suid ? I made changes to libc and tried them out with LD_PRELOAD=... test_progam. It worked as any user (including root), but not with suid settings. Justus explained why not. well i did too but is that all ? i mean, why did you test with suid programs in the first place ? to get different euid and egid numbers hi, anybody seen this with eglibc-2.17-96: locale: relocation error: locale: symbol errno, version GLIBC_PRIVATE not defined in file libc.so.0.3 with link time reference yes, I have but afaics nothing did break, so I ignored it ## IRC, freenode, #hurd, 2013-11-23 Finally 8-) Good news: soon both SCM_CREDS _and_ SCM_RIGHTS is supported jointly. RFCs will be sent soon. ## IRC, freenode, #hurd, 2013-12-05 I have a problem with the SCM_CREDS patch and dbus. gamin and my test code runs fine. the problem with the dbus code is that it won't work well with auth_user_authenticate in sendmsg and auth_server_authenticate in recvmsg. Should I try to modify the dbus code to make it work? unless you manage to prove that dbus is not following the posix standard, there is no reason why you should have to modify dbus I think the implementation is correct, but auth_user_authenticate hangs sendmsg until auth_seerver_authenticate is executed in recvmsg. and dbus is not doing that, so it hangs in sendmsg writing a credentials byte. well the credentials byte is definitely non-posix. I found a bug related to the HURD_DPORT_USE macro too:-( ah, yes, auth_user_authenticate might be synchronous indeed, let me think about it Nevertheless, I think it's time to publish the code so it can be commented on:-D sure publish early, publish often # IRC, freenode, #hurd, 2014-01-17 youpi: as a start all our requested dbus changes are now committed, and in Debian unstable good :) # IRC, freenode, #hurd, 2014-01-30 dbus has some known problems known fixes too? http://www.gnu.org/software/hurd/open_issues/dbus.html pochu: Maybe that page should be updated: http://lists.nongnu.org/archive/html/bug-hurd/2013-12/msg00150.html gnu_srs: well, maybe you can do it : )