summaryrefslogtreecommitdiff
path: root/open_issues/dbus.mdwn
blob: 2f02579eb73661877a62b1954a865300f50bd840 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
[[!meta copyright="Copyright © 2011, 2012 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.

---

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