Description of problem:
I'm trying to get a dbus session which talks over TCP.  The dbus-daemon starts as expected, but no clients can connect.


Version-Release number of selected component (if applicable):
dbus-1.6.8-2.fc18.x86_64
libselinux-2.1.12-7.fc18.x86_64
kernel-3.6.10-4.fc18.x86_64


How reproducible:
Every time


Steps to Reproduce:
The reason I want to use dbus over TCP is of course that I want to communicate between hosts.  But for testing purposes, I do all the following on a single host.  The problem happens in this case too.

1. Configure dbus to also open a TCP socket by putting this in /etc/dbus-1/session-local.conf

<!DOCTYPE busconfig PUBLIC
 "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
  <listen>tcp:host=freddi</listen>
</busconfig>

"freddi" is the name of the host I'm doing this experiment on.

2. Start a new dbus session: dbus-daemon --session --print-address
3. Set DBUS_SESSION_BUS_ADDRESS to the value dbus-daemon wrote, something like:

tcp:host=freddi,port=34950,guid=c0ad24bb37b13b231285aa1750dd999d;unix:abstract=/tmp/dbus-c63h7VviuW,guid=89b218d054ac7f0c4b4f325f50dd999d

4. Run in background: rhythmbox
5. Run: rhythmbox-client --print-volume


Actual results:
rhythmbox prints warnings:
** (rhythmbox:3467): WARNING **: failed to commit changes to dconf: Fel vid sändning av data: Brutet rör

(The end says approximately: Error while sending data: Broken pipe).

rhythmbox-client prints nothing at all.


Expected results:
No, or at least fewer, warnings from rhythmbox, the volume of the running rhythmbox printed by rhythmbox-client.


Additional info:
I tried to investigate this a bit more.  The rhythmbox-client fails because its connection to the dbus is closed down by the server.  Here is the end of an strace:

socket(PF_INET, SOCK_STREAM|SOCK_CLOEXEC, IPPROTO_IP) = 5
fcntl(5, F_GETFD)                       = 0x1 (flags FD_CLOEXEC)
fcntl(5, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(5, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
connect(5, {sa_family=AF_INET, sin_port=htons(34950), sin_addr=inet_addr("172.17.0.3")}, 16) = -1 EINPROGRESS (Operation now in progress)
poll([{fd=5, events=POLLOUT}], 1, 4294967295) = 1 ([{fd=5, revents=POLLOUT}])
getsockopt(5, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
poll([{fd=5, events=POLLOUT}], 1, 4294967295) = 1 ([{fd=5, revents=POLLOUT}])
sendto(5, "\0", 1, MSG_NOSIGNAL, NULL, 0) = 1
poll([{fd=5, events=POLLOUT}], 1, 4294967295) = 1 ([{fd=5, revents=POLLOUT|POLLERR|POLLHUP}])
poll([{fd=5, events=POLLOUT}], 1, 4294967295) = 1 ([{fd=5, revents=POLLOUT|POLLERR|POLLHUP}])
sendto(5, "AUTH\r\n", 6, MSG_NOSIGNAL, NULL, 0) = -1 EPIPE (Broken pipe)
close(5)                                = 0
exit_group(0)                           = ?

So I looked at what the dbus-daemon does in a debugger.  It seems the critical thing that goes wrong is when it tries to figure out the SELinux context of its peer.  The backtrace is as follows:

#0  getpeercon_raw_internal (fd=10, context=context@entry=0x7fff7b335ae8) at getpeercon.c:27
#1  0x00007fbb47361c52 in getpeercon (fd=<optimized out>, context=context@entry=0x7fff7b335b00) at getpeercon.c:53
#2  0x0000000000414874 in bus_connection_read_selinux_context (con=0x7fff7b335b00, connection=0x922e10) at selinux.c:714
#3  bus_selinux_init_connection_id (connection=connection@entry=0x922e10, error=error@entry=0x7fff7b335b30) at selinux.c:743
#4  0x000000000040d3b9 in bus_connections_setup_connection (connections=0x9104d0, connection=connection@entry=0x922e10) at connection.c:627
#5  0x0000000000407ab5 in new_connection_callback (server=server@entry=0x910210, new_connection=new_connection@entry=0x922e10, data=data@entry=0x90a0e0) at bus.c:172
#6  0x000000000042973b in handle_new_client_fd_and_unlock (client_fd=<optimized out>, server=0x910210) at dbus-server-socket.c:145
#7  socket_handle_watch (watch=<optimized out>, flags=<optimized out>, data=0x910210) at dbus-server-socket.c:209
#8  0x000000000042df7a in dbus_watch_handle (watch=watch@entry=0x90faf0, flags=flags@entry=1) at dbus-watch.c:700
#9  0x0000000000439a94 in _dbus_loop_iterate (loop=loop@entry=0x90b0f0, block=block@entry=1) at dbus-mainloop.c:842
#10 0x0000000000439c7d in _dbus_loop_run (loop=0x90b0f0) at dbus-mainloop.c:906
#11 0x0000000000404c16 in main (argc=<optimized out>, argv=<optimized out>) at main.c:634

What happens here is that dbus in bus_connection_read_selinux_context tries to figure out the SELinux context of its peer.  This is done calling getpeercon() which indirectly calls getsockopt(fd, SOL_SOCKET, SO_PEERSEC, ...) on the received socket.

This call fails with errno set to 92 (ENOPROTOOPT).  And after that, dbus-daemon gives up, closes the connection, and the client exits.

I get the impression that getpeercon()/getsockopt(SO_PEERSEC) isn't supported for TCP sockets.  If it had been a remote connection, I not sure how it COULD be supported.  If this is correct, then the bug is that dbus-daemon tries to get the context of its peer when contacted via TCP.

But I might of course be completely wrong again.