diff options
Diffstat (limited to 'open_issues/dbus.mdwn')
| -rw-r--r-- | open_issues/dbus.mdwn | 502 |
1 files changed, 0 insertions, 502 deletions
diff --git a/open_issues/dbus.mdwn b/open_issues/dbus.mdwn deleted file mode 100644 index b3bebf48..00000000 --- a/open_issues/dbus.mdwn +++ /dev/null @@ -1,502 +0,0 @@ -[[!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> ) |