<div dir="ltr"><div><div><div><div>Hi Stewart,<br><br></div> 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". <br><br></div> Even you also faced same issue? Any thing you did to solve this?<br><br></div>Thanks,<br></div>Adithya<br><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2017-03-10 20:44 GMT+05:30 Stewart Brodie <span dir="ltr"><<a href="mailto:sbrodie@espial.com" target="_blank">sbrodie@espial.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Adithya K <<a href="mailto:linux.challenge1@gmail.com">linux.challenge1@gmail.com</a>> wrote:<br>
<br>
> > > I am usig busybox  template to create container on ubuntu. I am<br>
> > > creating container as non  privilage. Attached is the config created.<br>
> > > I am mapping var/run/duns/socket from host to container. Basically I<br>
> > > am using host dbus.<br>
<br>
> > > What I see is when I try to run and dbus program,<br>
> > > dbus_bus_get(DBUS_BUS_SYSTEM, &err); call fails. Basically I am not<br>
> > > able to get dbus bus connection.<br>
<br>
</span><span class="">> > > When I create container using privilage mode, then this issue doesn't<br>
> > > exist.<br>
<br>
> > > Any solution for this issue.<br>
<br>
<br>
</span>This will not work (as you have discovered!)  This is why ...<br>
<br>
The dbus-daemon examines the credentials on the UNIX domain socket, in order<br>
to find out the peer's PID and UID.  If the peer is in a different PID<br>
and/or UID namespace, the kernel will have remapped the credentials into the<br>
dbus-daemon's namespace.  The client, however, will still try to<br>
authenticate by passing its UID in the SASL setup for the connection by<br>
sending "AUTH EXTERNAL <UID>", where <UID> is a hex version of the<br>
stringification of the effective UID of the client in *its* namespace.  e.g.<br>
the UID 789 would be encoded as 373839!  Thus when the dbus-daemon receives<br>
this UID and compares it to the credentials it found on the socket, it finds<br>
the UIDs don't match and thus it refuses to permit the connection.<br>
<br>
For my project, I can afford to disable the SASL part of the connection<br>
protocol in the client - it would be possible to fix this in the daemon, but<br>
for various reasons I can't do that in my project.  The obvious problem of<br>
patching the client rather than the server is that you end up having to<br>
patch all the different client DBus libraries.<br>
<br>
I attach an example patch for dbox-1.10.6 that *disables* the sending of the<br>
client UID in the setup message.  If that's acceptable for your situation,<br>
you're welcome to use it.  There's a second patch for GDBus too.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Stewart Brodie<br>
Senior Software Engineer<br>
Espial UK<br>
<br>
</font></span><br>______________________________<wbr>_________________<br>
lxc-users mailing list<br>
<a href="mailto:lxc-users@lists.linuxcontainers.org">lxc-users@lists.<wbr>linuxcontainers.org</a><br>
<a href="http://lists.linuxcontainers.org/listinfo/lxc-users" rel="noreferrer" target="_blank">http://lists.linuxcontainers.<wbr>org/listinfo/lxc-users</a><br></blockquote></div><br></div></div></div></div></div>