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

Sun Apr 14 20:42:54 UTC 2013

On 04/14/2013 09:56 PM, S.Çağlar Onur wrote:
> Hi all,
>
> I had some free time today so I tried to implement something using
> AF_INET messages over loopback broadcast address. I'm not including
> the patch here because gmail web interface damages it and that's what
> I use right now so please use [1] to see it. 
>
> I'm sending it to get your feedback and will submit it to list if you
> are OK with that approach.
>
> P.S: I used 51423 as the port but of course it can be changed
> accordingly.
>
> [1]
> https://github.com/caglar10ur/lxc-upstream/commit/123b20e2945ed2b4bc9e6e27b9ef398ec8fcae40.patch

Thanks for this code !

It sounds like the approach seems ok. My concern is the same than Serge,
what can we do to ensure an event was sent by a container ?

We don't want someone to send fake events via UDP. We can't tolerate a
simple program messing a container supervisor and all the containers
(running an OS instance).

Assuming an user, which is not root, can't build an IP packet, we can
rely on the IP identification number to detect fake packets, no ?

> On Fri, Apr 12, 2013 at 5:31 PM, Daniel Lezcano
> <daniel.lezcano at free.fr <mailto:daniel.lezcano at free.fr>> wrote:
>
>     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>
>     <mailto: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>
>     >     <mailto: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>
>     >     <mailto: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>
>     <mailto:caglar at 10ur.org <mailto:caglar at 10ur.org>>>
>
>
>
>
> -- 
> S.Çağlar Onur <caglar at 10ur.org <mailto:caglar at 10ur.org>>