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 <sbro...@espial.com>: > Adithya K <linux.challen...@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@lists.linuxcontainers.org > http://lists.linuxcontainers.org/listinfo/lxc-users >
/ # 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) / # / #
_______________________________________________ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
