Re: [lxc-users] Unprivileged containers on Debian Jessie
Hi Serge, I did some tries with Ubuntu 14.04 and you are right, this does not make things easier. Thus, I came back to Debian Jessie and I have written a small tool to automate the configuration tweaks, create the useful cgroups and autostart the unprivileged containers on boot. This is a very basic script but it does the job for what I need and I think this is sufficient for classical use. To remain in the maritime vocabulary, I called it Mithlond and it can be downloaded from GitHub: https://github.com/Meseira/mithlond I hope this can help. Xavier Le 09/02/2015 18:29, Serge Hallyn a écrit : Quoting Xavier Gendre (gendre.rei...@gmail.com): Thanks for your answer. Indeed, it only needs to be done at login and this is my problem. Your solutions work well but all need to login at least one time for each user with unprivileged containers. I admit that my question was not clear :-° My goal is to autostart the unprivileged containers when the machine starts, i.e. before any user can login. I have seen solutions based cgm with Ubuntu on internet, maybe it works on Debian Jessie too... I have to try harder or change to Ubuntu server ;-) Hm, if you want to autostart unprivileged containers then switching to ubuntu still may not help. On my (ubuntu trusty) server I do autostart userns containers, but they are owned/started by root, with lxc.id_map entries. That way root has the rights to create its cgroups, as well as (more importantly for me) mount rootfs from lvm devices. Xavier Le 05/02/2015 16:56, Serge Hallyn a écrit : Quoting Xavier Gendre (gendre.rei...@gmail.com): Hi, following the hints given by Serge Hallyn on the lxc-devel list, I managed to run an unprivileged container on my Debian Jessie \o/ Now, I want to avoid handlings and get it works on startup. Thus, I set permanently kernel.unprivileged_userns_clone to 1 and I create a systemd service to run the following script: #!/bin/bash echo 1 > /sys/fs/cgroup/cpuset/cgroup.clone_children # Allowed users lxc_users="user1 user2" for u in $lxc_users; do for d in /sys/fs/cgroup/*; do mkdir -p $d/$u chown -R $u: $d/$u done done The only thing that I need now is to put a 'good' PID in the tasks files in order to be allowed to start my unprivileged containers. I can do that by login as an allowed user and by putting the PID of the current shell in my tasks file. But this solution is volatile and has to be done on each startup for each container :-/ No, it only needs to be done at login right? You've already chowned the cgroups to your user, so you should be able to just do it from your .bashrc or equivalent. Or, you could whip up a quick pam module to do it. Is my approach good? Maybe there is a simpler solution to my problem... If this is the way, how can I put a valid PID in the tasks files of the allowed users on startup in order, for example, to autostart some unprivileged containers? Thanks, Xavier ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] Seg fault when using VLAN mode network
Serge Hallyn writes: > > Quoting Serge Hallyn (serge.hallyn ubuntu.com): > > Quoting Rory McCann (Rory.McCann riverbed.com): > .. > > > Now, after exiting the container and re-running the lxc-execute command, I straightaway get a > segmentation fault, and the following kernel stacktrace: > > > > > > [ 169.728142] [ cut here ] > > > [ 169.728151] WARNING: CPU: 0 PID: 1382 at /build/buildd/linux-3.13.0/fs/sysfs/dir.c:486 sysfs_warn_dup+0x86/0xa0() > > > [ 169.728153] sysfs: cannot create duplicate filename '/devices/pci:00/:00:16.0/:0b:00.0/net/eth1/upper_vlan10-0' > > > [ 169.728155] Modules linked in: 8021q garp mrp xt_CHECKSUM iptable_mangle ipt_MASQUERADE > iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack xt_tcpudp bridge stp > llc iptable_filter ip_tables x_tables ppdev coretemp crct10dif_pclmul crc32_pclmul > ghash_clmulni_intel vmw_balloon aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper > cryptd serio_raw vmwgfx ttm drm vmw_vmci parport_pc i2c_piix4 shpchp lp mac_hid parport psmouse > vmxnet3 mptspi mptscsih mptbase floppy > > > [ 169.728204] CPU: 0 PID: 1382 Comm: lxc-execute Not tainted 3.13.0-32-generic #57-Ubuntu > > > > I don't get this bug, and this appears to be a simple kernel bugl. Does > > eth1 exist? > > Oh, wow. I do get kernel lockups on a trusty box. When I upgrade to > the linux-image-generic-lts-utopic kernel, that goes away. Can you > try that? Thanks, upgrading to that kernel seems to have fixed the issue. (Sorry for the gmane-forwarded post - I forgot to subscribe before sending my first mail.) ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] Unprivileged containers on Debian Jessie
Cool, thanks, that is very nicely done :) I'll leave it to you and Stéphane to decide whether this ought to be integrated with the config scripts shipped in lxc or not. The way you have it set up doesn't appear to lose any of the protections for the host from the unprivileged users, so I'd be all for it. Quoting Xavier Gendre (gendre.rei...@gmail.com): > Hi Serge, > > I did some tries with Ubuntu 14.04 and you are right, this does not > make things easier. Thus, I came back to Debian Jessie and I have > written a small tool to automate the configuration tweaks, create > the useful cgroups and autostart the unprivileged containers on > boot. > > This is a very basic script but it does the job for what I need and > I think this is sufficient for classical use. > > To remain in the maritime vocabulary, I called it Mithlond and it > can be downloaded from GitHub: > > https://github.com/Meseira/mithlond > > I hope this can help. > > Xavier > > Le 09/02/2015 18:29, Serge Hallyn a écrit : > >Quoting Xavier Gendre (gendre.rei...@gmail.com): > >>Thanks for your answer. Indeed, it only needs to be done at login > >>and this is my problem. Your solutions work well but all need to > >>login at least one time for each user with unprivileged containers. > >> > >>I admit that my question was not clear :-° My goal is to autostart > >>the unprivileged containers when the machine starts, i.e. before any > >>user can login. > >> > >>I have seen solutions based cgm with Ubuntu on internet, maybe it > >>works on Debian Jessie too... I have to try harder or change to > >>Ubuntu server ;-) > > > >Hm, if you want to autostart unprivileged containers then > >switching to ubuntu still may not help. On my (ubuntu trusty) > >server I do autostart userns containers, but they are owned/started > >by root, with lxc.id_map entries. That way root has the rights > >to create its cgroups, as well as (more importantly for me) mount > >rootfs from lvm devices. > > > >>Xavier > >> > >>Le 05/02/2015 16:56, Serge Hallyn a écrit : > >>>Quoting Xavier Gendre (gendre.rei...@gmail.com): > Hi, > > following the hints given by Serge Hallyn on the lxc-devel list, I > managed to run an unprivileged container on my Debian Jessie \o/ > > Now, I want to avoid handlings and get it works on startup. Thus, I > set permanently kernel.unprivileged_userns_clone to 1 and I create a > systemd service to run the following script: > > #!/bin/bash > > echo 1 > /sys/fs/cgroup/cpuset/cgroup.clone_children > > # Allowed users > lxc_users="user1 user2" > > for u in $lxc_users; do > for d in /sys/fs/cgroup/*; do > mkdir -p $d/$u > chown -R $u: $d/$u > done > done > > The only thing that I need now is to put a 'good' PID in the tasks > files in order to be allowed to start my unprivileged containers. I > can do that by login as an allowed user and by putting the PID of > the current shell in my tasks file. But this solution is volatile > and has to be done on each startup for each container :-/ > >>> > >>>No, it only needs to be done at login right? You've already chowned > >>>the cgroups to your user, so you should be able to just do it from > >>>your .bashrc or equivalent. Or, you could whip up a quick pam module > >>>to do it. > >>> > Is my approach good? Maybe there is a simpler solution to my > problem... If this is the way, how can I put a valid PID in the > tasks files of the allowed users on startup in order, for example, > to autostart some unprivileged containers? > > Thanks, > Xavier > >>___ > >>lxc-users mailing list > >>lxc-users@lists.linuxcontainers.org > >>http://lists.linuxcontainers.org/listinfo/lxc-users > >___ > >lxc-users mailing list > >lxc-users@lists.linuxcontainers.org > >http://lists.linuxcontainers.org/listinfo/lxc-users > > > ___ > lxc-users mailing list > lxc-users@lists.linuxcontainers.org > http://lists.linuxcontainers.org/listinfo/lxc-users ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] Seg fault when using VLAN mode network
Quoting Rory McCann (rory.mcc...@riverbed.com): > Serge Hallyn writes: > > > > Quoting Serge Hallyn (serge.hallyn ubuntu.com): > > > Quoting Rory McCann (Rory.McCann riverbed.com): > > .. > > > > Now, after exiting the container and re-running the lxc-execute > command, I straightaway get a > > segmentation fault, and the following kernel stacktrace: > > > > > > > > [ 169.728142] [ cut here ] > > > > [ 169.728151] WARNING: CPU: 0 PID: 1382 at > /build/buildd/linux-3.13.0/fs/sysfs/dir.c:486 sysfs_warn_dup+0x86/0xa0() > > > > [ 169.728153] sysfs: cannot create duplicate filename > '/devices/pci:00/:00:16.0/:0b:00.0/net/eth1/upper_vlan10-0' > > > > [ 169.728155] Modules linked in: 8021q garp mrp xt_CHECKSUM > iptable_mangle ipt_MASQUERADE > > iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat > nf_conntrack xt_tcpudp bridge stp > > llc iptable_filter ip_tables x_tables ppdev coretemp crct10dif_pclmul > crc32_pclmul > > ghash_clmulni_intel vmw_balloon aesni_intel aes_x86_64 lrw gf128mul > glue_helper ablk_helper > > cryptd serio_raw vmwgfx ttm drm vmw_vmci parport_pc i2c_piix4 shpchp lp > mac_hid parport psmouse > > vmxnet3 mptspi mptscsih mptbase floppy > > > > [ 169.728204] CPU: 0 PID: 1382 Comm: lxc-execute Not tainted > 3.13.0-32-generic #57-Ubuntu > > > > > > I don't get this bug, and this appears to be a simple kernel bugl. Does > > > eth1 exist? > > > > Oh, wow. I do get kernel lockups on a trusty box. When I upgrade to > > the linux-image-generic-lts-utopic kernel, that goes away. Can you > > try that? > > > Thanks, upgrading to that kernel seems to have fixed the issue. > > (Sorry for the gmane-forwarded post - I forgot to subscribe before sending > my first mail.) Would you mind sending a bug report against the ubuntu 14.04 linux package? ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] macvlan-based networking for unprivileged containers
Quoting Fajar A. Nugraha (l...@fajar.net): > On Mon, Feb 16, 2015 at 9:52 PM, Serge Hallyn wrote: > > Quoting overlay fs (overla...@gmail.com): > > >> > > However veth works > >> > > just fine. And you don't have to put your public link (e.g. eth0) on > >> > > bridge mode to have a working container with veth network. > >> > > >> > FWIW what it would take is an extension to lxc-user-nic to support > >> > (accounted) unpriv macvlan. /etc/lxc/lxc-usernet would then support > >> > something like "$user macvlan eth0 10". > >> > > >> > But as Fajar says, the value of this seems dubious, and I'm not sure > >> > whether that would have the same snooping-on-same-link concerns > >> > that you'd have with a bridged eth0. > >> > >> Is there presently a way to block network traffic between unprivileged > >> containers, or between a container and the host? This could be > >> desirable when running untrusted containers. > > > > You (your administrator) could create separate bridges for each user. > > It might be useful to enhance lxc-user-nic to allow: > - setting lxc.network.veth.pair To do this, we'd have to provide a way for admins to specify which pair names a given user may use. But I see below you'd be doing that anyway, > - allow veth without bridge (i.e. no lxc.network.link line on config file) > > With those two capabilities you could make routed setup without any > bridge, where all containers route their traffic thru the host similar > to the way pptp works. Containers can have IPs in the same segment as > eth0, but can't see traffic meant to other IPs thru link-snooping. In > this setup you DON'T need separate bridges for each user/container, > but you DO need a config stanza (including fixed IP allocation) on > host's /etc/network/interfaces for each container. > > This setup currently works on my test setup, privileged container. It > also works for have root-started unprivileged container (i.e. created > and started by root in /var/lib/lxc, but uses "lxc.include = > /usr/share/lxc/config/ubuntu.userns.conf" and lxc.id_map) since it > doesn't use lxc-user-nic. It does NOT work user-started unprivileged > container. > > Assuming: > - your public link is eth0, 192.168.124.30/24 (LAN address in my test setup) > - your containers (c1 and c2) gets IP address 192.168.124.251 and > 192.168.124.252 > - you allocate private IP 172.16.0.1 for container's gateway (can be > any private IP of your choice) > > > ## > Host setup > ## > > /etc/network/interfaces (if using ubuntu). > ### > auto lo > iface lo inet loopback > > auto eth0 > iface eth0 inet static > address 192.168.124.130 > netmask 255.255.255.0 > gateway 192.168.124.1 > > # c1's veth name on host side > auto v-c1-0 > iface v-c1-0 inet static I'm probably just ignorant here, but - does this not cause 'ifup -a' to fail when the containers are not up? > address 172.16.0.1/32 > scope link > pointopoint 192.168.124.251 > > # c2's veth name on host side > auto v-c2-0 > iface v-c2-0 inet static > # note that this is the same IP as above, not a typo > address 172.16.0.1/32 > scope link > # c2's IP > pointopoint 192.168.124.252 > ### ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] Seg fault when using VLAN mode network
Quoting Serge Hallyn (serge.hal...@ubuntu.com): > Quoting Rory McCann (rory.mcc...@riverbed.com): > > Serge Hallyn writes: > > > > > > Quoting Serge Hallyn (serge.hallyn ubuntu.com): > > > > Quoting Rory McCann (Rory.McCann riverbed.com): > > > .. > > > > > Now, after exiting the container and re-running the lxc-execute > > command, I straightaway get a > > > segmentation fault, and the following kernel stacktrace: > > > > > > > > > > [ 169.728142] [ cut here ] > > > > > [ 169.728151] WARNING: CPU: 0 PID: 1382 at > > /build/buildd/linux-3.13.0/fs/sysfs/dir.c:486 sysfs_warn_dup+0x86/0xa0() > > > > > [ 169.728153] sysfs: cannot create duplicate filename > > '/devices/pci:00/:00:16.0/:0b:00.0/net/eth1/upper_vlan10-0' > > > > > [ 169.728155] Modules linked in: 8021q garp mrp xt_CHECKSUM > > iptable_mangle ipt_MASQUERADE > > > iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat > > nf_conntrack xt_tcpudp bridge stp > > > llc iptable_filter ip_tables x_tables ppdev coretemp crct10dif_pclmul > > crc32_pclmul > > > ghash_clmulni_intel vmw_balloon aesni_intel aes_x86_64 lrw gf128mul > > glue_helper ablk_helper > > > cryptd serio_raw vmwgfx ttm drm vmw_vmci parport_pc i2c_piix4 shpchp lp > > mac_hid parport psmouse > > > vmxnet3 mptspi mptscsih mptbase floppy > > > > > [ 169.728204] CPU: 0 PID: 1382 Comm: lxc-execute Not tainted > > 3.13.0-32-generic #57-Ubuntu > > > > > > > > I don't get this bug, and this appears to be a simple kernel bugl. Does > > > > eth1 exist? > > > > > > Oh, wow. I do get kernel lockups on a trusty box. When I upgrade to > > > the linux-image-generic-lts-utopic kernel, that goes away. Can you > > > try that? > > > > > > Thanks, upgrading to that kernel seems to have fixed the issue. > > > > (Sorry for the gmane-forwarded post - I forgot to subscribe before sending > > my first mail.) > > Would you mind sending a bug report against the ubuntu 14.04 linux package? Looks like we already have one, thanks. ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
[lxc-users] Change selinux context of /sys and /proc inside container
Is there a way to alter the selinux context of certain directories or files in /proc and /sys inside the container? AppArmor looks to have the an easier config in this matter but I can't seem to get it to build correctly on Fedora 21. Most of these files share the same context, so I don't see a way to change selinux settings on certain files without changing their context, which I assume would need to be done somewhere in the configuration or with a hook. Thanks in advance, Devon ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
Re: [lxc-users] macvlan-based networking for unprivileged containers
On Wed, Feb 18, 2015 at 12:27 AM, Serge Hallyn wrote: > Quoting Fajar A. Nugraha (l...@fajar.net): >> # c1's veth name on host side >> auto v-c1-0 >> iface v-c1-0 inet static > > I'm probably just ignorant here, but - does this not cause 'ifup -a' to > fail when the containers are not up? ifup throws an error message, but still exit with code 0, so it should be safe. udev and network-interface service will kick in to automatically activate it when the interface becomes available (i.e. when the container is started) # ifup -a;echo $? Cannot find device "v-c1-0" Failed to bring up v-c1-0. 0 # ifup v-c1-0;echo $? Cannot find device "v-c1-0" Failed to bring up v-c1-0. 0 -- Fajar ___ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
