Re: [lxc-devel] Detecting if you are running in a container
On Mon, Oct 10, 2011 at 23:41, Lennart Poettering wrote: > On Mon, 10.10.11 13:59, Eric W. Biederman (ebied...@xmission.com) wrote: >> - udev. All of the kernel interfaces for udev should be supported in >> current kernels. However I believe udev is useless because container >> start drops CAP_MKNOD so we can't do evil things. So I would >> recommend basing the startup of udev on presence of CAP_MKNOD. > > Using CAP_MKNOD as test here is indeed a good idea. I'll make sure udev > in a systemd world makes use of that. Done. http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=9371e6f3e04b03692c23e392fdf005a08ccf1edb Thanks, Kay -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [systemd-devel] [PATCH] netns: unix: only allow to find out unix socket in same net namespace
On Wed, Aug 21, 2013 at 9:22 AM, Gao feng wrote: > On 08/21/2013 03:06 PM, Eric W. Biederman wrote: >> I suspect libvirt should simply not share /run or any other normally >> writable directory with the host. Sharing /run /var/run or even /tmp >> seems extremely dubious if you want some kind of containment, and >> without strange things spilling through. Right, /run or /var cannot be shared. It's not only about sockets, many other things will also go really wrong that way. > right now I only take note of the unix socket /run/systemd/private, > but there may have many similar unix sockets, they can exist in any > path. the strange problems will still happen. > > anyway, I will send a patch to setup a fresh tmpfs for the /run directory of > container first. This is what systemd-nspawn does for a container setup: http://cgit.freedesktop.org/systemd/systemd/tree/src/nspawn/nspawn.c#n350 Kay -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [systemd-devel] [PATCH] netns: unix: only allow to find out unix socket in same net namespace
On Sun, Aug 25, 2013 at 7:16 PM, James Bottomley wrote: > On Wed, 2013-08-21 at 11:51 +0200, Kay Sievers wrote: >> On Wed, Aug 21, 2013 at 9:22 AM, Gao feng wrote: >> > On 08/21/2013 03:06 PM, Eric W. Biederman wrote: >> >> >> I suspect libvirt should simply not share /run or any other normally >> >> writable directory with the host. Sharing /run /var/run or even /tmp >> >> seems extremely dubious if you want some kind of containment, and >> >> without strange things spilling through. >> >> Right, /run or /var cannot be shared. It's not only about sockets, >> many other things will also go really wrong that way. > > This is very narrow thinking about what a container might be and will > cause trouble as people start to create novel uses for containers in the > cloud if you try to impose this on our current infrastructure. > > One of the cgroup only container uses we see at Parallels (so no > separate filesystem and no net namespaces) is pure apache load balancer > type shared hosting. In this scenario, base apache is effectively > brought up in the host environment, but then spawned instances are > resource limited using cgroups according to what the customer has paid. > Obviously all apache instances are sharing /var and /run from the host > (mostly for logging and pid storage and static pages). The reason some > hosters do this is that it allows much higher density simple web serving > (either static pages from quota limited chroots or dynamic pages limited > by database space constraints) because each "instance" shares so much > from the host. The service is obviously much more basic than giving > each customer a container running apache, but it's much easier for the > hoster to administer and it serves the customer just as well for a large > cross section of use cases and for those it doesn't serve, the hoster > usually has separate container hosting (for a higher price, of course). The "container" as we talk about has it's own init, and no, it cannot share /var or /run. The stuff you talk about has nothing to do with that, it's not different from all services or a multi-instantiated service on the host sharing the same /run and /var. Kay -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
