[lxc-users] DBUS connection from inside container using system dbus

Adithya K linux.challenge1 at gmail.com
Mon Mar 13 16:07:02 UTC 2017


Hi Stewart,

 Thanks for the response. With your fix it went ahead but didn't solve the
problem. Now what I am seeing is server is closing the connection before
message is processed. So it is dropped. See attached log and "Not
connected, not writing anything".

 Even you also faced same issue? Any thing you did to solve this?

Thanks,
Adithya

2017-03-10 20:44 GMT+05:30 Stewart Brodie <sbrodie at espial.com>:

> Adithya K <linux.challenge1 at gmail.com> wrote:
>
> > > > I am usig busybox  template to create container on ubuntu. I am
> > > > creating container as non  privilage. Attached is the config created.
> > > > I am mapping var/run/duns/socket from host to container. Basically I
> > > > am using host dbus.
>
> > > > What I see is when I try to run and dbus program,
> > > > dbus_bus_get(DBUS_BUS_SYSTEM, &err); call fails. Basically I am not
> > > > able to get dbus bus connection.
>
> > > > When I create container using privilage mode, then this issue doesn't
> > > > exist.
>
> > > > Any solution for this issue.
>
>
> This will not work (as you have discovered!)  This is why ...
>
> The dbus-daemon examines the credentials on the UNIX domain socket, in
> order
> to find out the peer's PID and UID.  If the peer is in a different PID
> and/or UID namespace, the kernel will have remapped the credentials into
> the
> dbus-daemon's namespace.  The client, however, will still try to
> authenticate by passing its UID in the SASL setup for the connection by
> sending "AUTH EXTERNAL <UID>", where <UID> is a hex version of the
> stringification of the effective UID of the client in *its* namespace.
> e.g.
> the UID 789 would be encoded as 373839!  Thus when the dbus-daemon receives
> this UID and compares it to the credentials it found on the socket, it
> finds
> the UIDs don't match and thus it refuses to permit the connection.
>
> For my project, I can afford to disable the SASL part of the connection
> protocol in the client - it would be possible to fix this in the daemon,
> but
> for various reasons I can't do that in my project.  The obvious problem of
> patching the client rather than the server is that you end up having to
> patch all the different client DBus libraries.
>
> I attach an example patch for dbox-1.10.6 that *disables* the sending of
> the
> client UID in the setup message.  If that's acceptable for your situation,
> you're welcome to use it.  There's a second patch for GDBus too.
>
>
> --
> Stewart Brodie
> Senior Software Engineer
> Espial UK
>
>
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20170313/887f1f29/attachment.html>
-------------- next part --------------
/ # dbus receive
Listening for signals
Filling in system bus address...
  used default system bus "unix:path=/var/run/dbus/system_bus_socket"
Filling in session bus address...
  "autolaunch:"
Filling in activation bus address...
  "none set"
opening shared connection to: unix:path=/var/run/dbus/system_bus_socket
checking for existing connection
creating shared_connections hash table
  successfully created shared_connections
client: going from state NeedSendAuth to state WaitingForData
Initialized transport on address unix:path=/var/run/dbus/system_bus_socket
LOCK
UNLOCK
LOCK
UNLOCK
LOCK
UNLOCK
LOCK
Message 0x1c72c10 (method_call /org/freedesktop/DBus org.freedesktop.DBus Hello '') for org.freedesktop.DBus added to outgoing queue 0x1c72918, 1 pending to send
Message 0x1c72c10 serial is 1
start
UNLOCK
locking io_path_mutex
start connection->io_path_acquired = 0 timeout = 0
end connection->io_path_acquired = 1 we_acquired = 1
unlocking io_path_mutex
LOCK
Transport iteration flags 0x1 timeout -1 connected = 1
client: Sent 16 bytes of: AUTH EXTERNAL 

Not authenticated, not writing anything
end
locking io_path_mutex
start connection->io_path_acquired = 1
unlocking io_path_mutex
end
dispatch status = complete is_connected = 1
UNLOCK
LOCK
UNLOCK
LOCK
doing iteration in
start
UNLOCK
locking io_path_mutex
start connection->io_path_acquired = 0 timeout = -1
end connection->io_path_acquired = 1 we_acquired = 1
unlocking io_path_mutex
LOCK
Transport iteration flags 0x7 timeout -1 connected = 1
UNLOCK
LOCK
client: got command "DATA"
end
locking io_path_mutex
start connection->io_path_acquired = 1
unlocking io_path_mutex
end
doing iteration in
start
UNLOCK
locking io_path_mutex
start connection->io_path_acquired = 0 timeout = -1
end connection->io_path_acquired = 1 we_acquired = 1
unlocking io_path_mutex
LOCK
Transport iteration flags 0x7 timeout -1 connected = 1
UNLOCK
LOCK
client: Sent 6 bytes of: DATA

Not authenticated, not writing anything
end
locking io_path_mutex
start connection->io_path_acquired = 1
unlocking io_path_mutex
end
doing iteration in
start
UNLOCK
locking io_path_mutex
start connection->io_path_acquired = 0 timeout = -1
end connection->io_path_acquired = 1 we_acquired = 1
unlocking io_path_mutex
LOCK
Transport iteration flags 0x7 timeout -1 connected = 1
UNLOCK
LOCK
client: got command "OK 391d7b5b26b797c8dc92e1f658c64367"
Got GUID '391d7b5b26b797c8dc92e1f658c64367' from the server
client: going from state WaitingForData to state WaitingForAgreeUnixFD
end
locking io_path_mutex
start connection->io_path_acquired = 1
unlocking io_path_mutex
end
doing iteration in
start
UNLOCK
locking io_path_mutex
start connection->io_path_acquired = 0 timeout = -1
end connection->io_path_acquired = 1 we_acquired = 1
unlocking io_path_mutex
LOCK
Transport iteration flags 0x7 timeout -1 connected = 1
UNLOCK
LOCK
client: Sent 19 bytes of: NEGOTIATE_UNIX_FD

Not authenticated, not writing anything
end
locking io_path_mutex
start connection->io_path_acquired = 1
unlocking io_path_mutex
end
doing iteration in
start
UNLOCK
locking io_path_mutex
start connection->io_path_acquired = 0 timeout = -1
end connection->io_path_acquired = 1 we_acquired = 1
unlocking io_path_mutex
LOCK
Transport iteration flags 0x7 timeout -1 connected = 1
UNLOCK
LOCK
client: got command "AGREE_UNIX_FD"
Successfully negotiated UNIX FD passing
client: going from state WaitingForAgreeUnixFD to state Authenticated
end
locking io_path_mutex
start connection->io_path_acquired = 1
unlocking io_path_mutex
end
doing iteration in
start
UNLOCK
locking io_path_mutex
start connection->io_path_acquired = 0 timeout = -1
end connection->io_path_acquired = 1 we_acquired = 1
unlocking io_path_mutex
LOCK
Transport iteration flags 0x7 timeout -1 connected = 1
UNLOCK
LOCK
client: Sent 7 bytes of: BEGIN

end
locking io_path_mutex
start connection->io_path_acquired = 1
unlocking io_path_mutex
end
doing iteration in
start
UNLOCK
locking io_path_mutex
start connection->io_path_acquired = 0 timeout = -1
end connection->io_path_acquired = 1 we_acquired = 1
unlocking io_path_mutex
LOCK
Transport iteration flags 0x7 timeout -1 connected = 1
UNLOCK
LOCK
start
end
Not connected, not writing anything
end
locking io_path_mutex
start connection->io_path_acquired = 1
unlocking io_path_mutex
end
middle
 0 unused bytes sent to message loader
dispatch status = complete is_connected = 0
Dropping 1 outgoing messages since we're disconnected
Message 0x1c72c10 (method_call /org/freedesktop/DBus org.freedesktop.DBus Hello '') removed from outgoing queue 0x1c72918, 0 left to send
Sending disconnect message
Synthesized message 0x1c72dd0 added to incoming queue 0x1c72918, 1 incoming
UNLOCK
LOCK
UNLOCK
LOCK
Synthesized message 0x1c72a68 added to incoming queue 0x1c72918, 2 incoming
dbus_connection_send_with_reply_and_block(): will block 25000 milliseconds for reply serial 1 from 8933 sec 29934 usec
checked for reply
dbus_connection_send_with_reply_and_block(): got reply
UNLOCK
LOCK
UNLOCK
LOCK
UNLOCK
LOCK
Disconnecting 0x1c72918
start
UNLOCK
Connection Error (Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was)
/ # 
/ # 



More information about the lxc-users mailing list