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

S.Çağlar Onur caglar at 10ur.org
Wed Apr 17 03:34:48 UTC 2013


Hi there,

What about using AF_INET but binding a restricted port while adding a new
field to the message? As an example we can start to create a hmac (or
something like that) per container in the creation time and save that into
LXCPATH/CONTAINERNAME/hmac. Then both client (can add that value to
message) and server (can read from filesystem to check authenticity of the
file) can use it.

By binding a restricted port we guarantee that regular users cannot sniff
the traffic and by using the filesystem permissions we provide the desired
separation?




On Tue, Apr 16, 2013 at 11:25 AM, Serge Hallyn <serge.hallyn at ubuntu.com>wrote:

> Quoting Dwight Engen (dwight.engen at oracle.com):
> > On Tue, 16 Apr 2013 08:52:56 -0500
> > Serge Hallyn <serge.hallyn at ubuntu.com> wrote:
> >
> > > Quoting S.Çağlar Onur (caglar at 10ur.org):
> > > > Hi Serge,
> > > >
> > > > I was just following your lead as you said you don't wan't any long
> > > > running monitor daemon :)
> > >
> > > Yup, at this point I"m going for the least bad solution.  (since the
> > > best solution, multicast af_unix, isn't possible :)
> > >
> > > > Also I'm not sure how does that daemon is going to help
> > > > starting multiple containers concurrently using only API. I'm
> > > > guessing the first request will cause that daemon to start and it
> > > > will never end unless specifically told it to shutdown?
> > >
> > > So basically,
> > >
> > >   c1  -                                --> m1
> > >         \                             /
> > >   c2  ----->  "\0$lxcpath" Daemon -------> m2
> > >         /                             \
> > >   c3  -/                               --> m3
> > >
> > > m1 is the first lxc-monitor someone started.  It sees that
> > > "\0$lxcpath" is not bound, so fires off a long-running daemon
> > > listening for events on "\0$lxcpath", and doing listen/accept at
> > > "\0$lxcpath.M".  Then m1 connects to to that daemon on "\0$lxcpath.M"
> > > and listens for events.  m2 starts, connects to "\0$lxcpath.M", and
> > > listens for events.  m3. does the same.  m1 exits, but the daemon
> > > continues.
> >
> > The daemon could keep track of how many monitors are connected and
> > exit when the count drops to zero (after waiting some small amount of
> > time for a new monitor connection which also handles the initial
> > startup case).
>
> Yup that sounds good :)
>
> > This daemon isn't queuing right? So we define that when there is no
> > monitor connected, all events are dropped.
>
> Yup, as is the case now.
>
> Anyone want to code a prototype?
>
> -serge
>



-- 
S.Çağlar Onur <caglar at 10ur.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20130416/4c017b04/attachment.html>


More information about the lxc-devel mailing list