Well if we really want to go that route, we can a. specify a monitor-port in $lxcpath/lxc.conf b. write a world-unreadable $lxcpath/monitor-secret file c. require catting $lxcpath/monitor-secret at initial connection
so /var/lib/lxc/lxc.conf can have monitor-port=9998, while /home/serge/lxcbase/lxc.conf has 9999, and /var/lib/lxc/monitor-secret has uber-secure password 'god' while /home/serge/lxcbase/monitor-secret contains 'mortal'. Now user serge can monitor his own containers on port 9999, but can't listen on port 9998. Of course we can still use a port < 1024 for root-owned containers for a bit more peace of mind. But what I don't like about this is that it requires more setup, whereas the AF_UNIX based solution requires no hand-cranking. I suppose we could make monitor-port, if unspecified, default to some-hash($lxcpath), and just say that the secret doesnt' have to be specified (I'm not sure everyone will care about container event spoofing). -serge Quoting S.Çağlar Onur (cag...@10ur.org): > Hi Serge, > > Yeah you are correct we need regular users to be able to monitor their own > containes. I guess we can encrypt the messages but I'm not going there :) > > Cheers, > > > On Wed, Apr 17, 2013 at 8:52 AM, Serge Hallyn <serge.hal...@ubuntu.com>wrote: > > > Quoting S.Çağlar Onur (cag...@10ur.org): > > > 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? > > > > But we want regular users to be able to monitor their own containers. > > > > Now I suppose we could require an extra netns layer where an > > unprivileged user must first create a new userns, create a new > > netns in that, and start containers from there. Then he has > > privilege over restricted ports in that netns, so he can monitor > > containers created from there. It also gives a somewhat simple > > way to provide networking to unprivileged-user-created containers- > > simply have a privileged init script create the userns+netns for > > the user, keeping it open, create a NIC in there and hook it into > > a host bridge (since this init job is privileged on the host), then > > hand the setns fd to the user (by bind-mounting into a DAC-protected > > directory like /lxc/ns/$USER/). Now the user can setns into > > /lxc/ns/$user before running any lxc commands. It's quite different > > from what I was earlier envisioning, but doable. Disclaimer: I'm > > groggy this morning, so might be talking sillyness. > > > > -serge > > > > > > -- > S.Çağlar Onur <cag...@10ur.org> ------------------------------------------------------------------------------ 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
