[lxc-devel] [PATCH] Use container specific domain socket name

Daniel Lezcano daniel.lezcano at free.fr
Fri Apr 12 21:31:08 UTC 2013


On 04/12/2013 06:55 PM, S.Çağlar Onur wrote:
> I'm not experienced with it so please forgive me if I'm talking
> non-sense but what about switching back to using (or abusing depending
> on your point of view) netlink via libnl?

Because it is much more than abusing :) It is hacking the rtnetlink
service, which means you filter out the messages not coming from lxc
(could be netlink messages about route changes, etc ...) and the
different tools relying on this netlink family must ignore lxc messages.

I will refresh my memory and implement a prototype based on af_inet
messages, that may take awhile because I am very busy for the moment.

Regards
  -- Daniel

> On Fri, Apr 12, 2013 at 10:02 AM, Serge Hallyn
> <serge.hallyn at ubuntu.com <mailto:serge.hallyn at ubuntu.com>> wrote:
>
>     Quoting Daniel Lezcano (daniel.lezcano at free.fr
>     <mailto:daniel.lezcano at free.fr>):
>     > Sorry for jumping so late in the thread but I disagree to use
>     DBUS with
>     > LXC because of the dependency with more packages, LXC has been
>     designed
>     > to be stand alone, nothing prevent to add more complexity and
>     > dependencies but on top of LXC not inside.
>     >
>     > To answer the previous email Serge sent me, I thought a bit
>     about the
>     > mechanism in order to prevent a publish/subscribe approach. The
>     first
>     > version used the af_netlink socket to use some kind of message
>     multicast
>     > on processes. But it hacked a family of the netlink which was
>     > conflicting with the ip_route tool. In order to prevent this
>     conflict I
>     > switched "temporarly" to the AF_UNIX socket while looking for a
>     socket
>     > type matching our needs. The AF_IPN (Inter Process Network)
>     could have
>     > been perfect but the patchset has been rejected.
>     >
>     > I think the solution to solve this issue is to use the AF_INET
>     protocol
>     > on the loopback using the loopback's broadcast address and
>     filter the
>     > messages with the container name. The code should be 'trivial'.
>     >
>     > One question remains with this approach : which communication
>     port number ?
>
>     A consideration:  right now the the monitors are per-lxcpath.  So
>     if user joe is using lxcpath /home/joe/lxcbase, then his lxc-monitor
>     will only hear events for containers under /home/joe/lxcbase.  If
>     we use loopback, then events for alllxcpaths on the host will be
>     combined.
>
>     That may be preferred, or may not be.  But in the coming world of
>     per-unprivileged-user containers, where user joe has container c2
>     in /home/joe/lxcbase/c2, do we want user joe to hear all events
>     relating to system containers (under /var/lib/lxc) or jane's
>     /home/jane/lxcbase containers?
>
>     It's not so much a noise issue, as we can just make sure to add
>     the lxcpath to each message.  It's more a security/privacy concern.
>
>     -serge
>
>     ------------------------------------------------------------------------------
>     Precog is a next-generation analytics platform capable of advanced
>     analytics on semi-structured data. The platform includes APIs for
>     building
>     apps and a phenomenal toolset for data science. Developers can use
>     our toolset for easy data analysis & visualization. Get a free
>     account!
>     http://www2.precog.com/precogplatform/slashdotnewsletter
>     _______________________________________________
>     Lxc-devel mailing list
>     Lxc-devel at lists.sourceforge.net
>     <mailto:Lxc-devel at lists.sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/lxc-devel
>
>
>
>
> -- 
> S.Çağlar Onur <caglar at 10ur.org <mailto:caglar at 10ur.org>>





More information about the lxc-devel mailing list