1. 15 Jan, 2013 4 commits
    • Implement userid mappings (enable user namespaces) · f6d3e3e4
      Serge Hallyn authored
      The 3.8 kernel now supporst uid mappings, so I believe it's appropriate
      to proceed with this patchset.
      The container config supports new entries of the form:
       lxc.id_map = U 100000 0 10000
       lxc.id_map = G 100000 0 10000
      meaning map 'virtual' uids (in the container) 0-10000 to uids
      100000-110000 on the host, and same for gids.  So long as there are
      mappings specified in the container config, then CONFIG_NEWUSER will
      be used when the container is cloned.  This means that container
      setup is no longer done with root privilege on the host, only root
      privilege in the container.  Therefore cgroup setup is moved from the
      init task to the monitor task.
      
      To use this patchset, you currently need to either use the raring
      kernel at ppa:serge-hallyn/usern-natty, or build your own kernel
      from either git://kernel.ubuntu.com/serge/quantal-userns.git.
      (Alternatively you can use Eric's tree at the latest userns-always-map-*
      branch at
      git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
      but you will likely want to at least enable tmpfs mounts in user namespaces)
      
      You also need to chown the files in the container rootfs into the
      mapped range.  There is a utility at
      https://code.launchpad.net/~serge-hallyn/+junk/nsexec to do this.
      uidmapshift does the chowning, while the container-userns-convert
      script nicely wraps that program.  So I simply
      
      	sudo lxc-create -t ubuntu -n r1
      	sudo container-userns-convert r1 200000
      
      will create a container which is shifted so uid 0 in the container
      is uid 200000 on the host.
      
      TODO: when doing setuid(0), need to only do that if 0 is one of the
      ids we map to.  Similarly, when dropping capabilities, need to only
      not do that if 0 is one of the ids we map to.  However, the question
      of what to do for 'weird' containers in private user namespaces is
      one I'm punting for later.
      Signed-off-by: 's avatarSerge Hallyn <serge.hallyn@ubuntu.com>
      Acked-by: 's avatarStéphane Graber <stgraber@ubuntu.com>
    • setup cgroups from parent · 544a48a0
      Serge Hallyn authored
      This is a first step to enabling user namespaces.  When starting a
      container in a new user namespace, the child will not have the
      rights to write to the cgroup fs.  (We can give it that right, but
      don't always want to have to).
      
      At the parent, we don't want to setup_cgroups() before the child
      has set itself up.  But we also don't want to wait until it has
      started running it's init, since that is racy.
      
      Therefore introduce a new sync point.  The child will let the
      parent know when it is ready to be confined, and wait for the
      parent to respond that it has done so.  Then the child will finish
      constraining itself with LSM and seccomp and execute init.
      Signed-off-by: 's avatarSerge Hallyn <serge.hallyn@ubuntu.com>
      Acked-by: 's avatarStéphane Graber <stgraber@ubuntu.com>
    • clean up syncs · c4ea60df
      Serge Hallyn authored
      Always unblock parent when child setup fails, rather than just
      exiting.
      
      Also remove a duplicate call to setup_cgroup().  We'll want it
      close to there for userns, but not right there - that's too late,
      and could happen after container init has done something bad
      without cgroup restrictions.
      Signed-off-by: 's avatarSerge Hallyn <serge.hallyn@ubuntu.com>
      Acked-by: 's avatarStéphane Graber <stgraber@ubuntu.com>
    • Multiple IP addresses: add them in the correct order · 8538f388
      Christian Seiler authored
      Make sure that when configuring containers that have interfaces containing
      multiple IP addresses they are added in the order of the configuration file
      (i.e. the first being the primary one) and not the reverse order.
      Signed-off-by: 's avatarChristian Seiler <christian@iwakd.de>
      Acked-by: 's avatarSerge E. Hallyn <serge.hallyn@ubuntu.com>
      Acked-by: 's avatarStéphane Graber <stgraber@ubuntu.com>
  2. 14 Jan, 2013 2 commits
    • MAKEDEV call, add autodev hooks, add environment variables for hook scripts. · f7bee6c6
      Michael H. Warfield authored
      Ok...  Here's the patch again.  Since Serge is removing the loglevel
      structure member, this patch no longer references that element.
      
      From the original description:
      
      1) Removes run_makedev() and the call to it from conf.c per discussion.
      
      2) Adds an lxc.hook.autodev hook.
      
      Note: This hook is very close (one routine level abstracted) from where
      the run_makedev was called.  Anyone really rrreeeaaalllyyy needing
      MAKEDEV can add it in with a small shim script to do whatever they want
      under whatever distro they're using, so no functionality is lost there.
      
      3) Added a number of environment variables for all the hook scripts to
      reference to assist in execution.  Things like LXC_ROOTFS_MOUNT could be
      very useful but others were added as well.  Room for more if anyone has
      an itch.  All in one spot in lxc_start.c.
      
      4) clearenv and putenv( "container=lxc" ) calls were moved to just after
      the "start" hook in the container just prior to actually firing up the
      container so we could use environment variables prior to that and have
      them flushed them before firing up init.  Nice side effect is that you
      can define environment variables and then call lxc-start and have them
      show up in those hooks scripts.
      
      5) I actually DID update the man page for lxc.conf!  I guess I lied when
      I said I wouldn't get that done.
      
      [... and ...]
      
      I added the rcfile to the lxc_conf structure as suggested and moved the
      setenv bundle from lxc-start.c over to start.c just prior to calling
      run_lxc_hooks for the pre-start hook.
      Signed-off-by: 's avatarMichael H. Warfield <mhw@WittsEnd.com>
      Signed-off-by: 's avatarSerge Hallyn <serge.hallyn@ubuntu.com>
    • remove logfile and loglevel from struct lxc_conf · 9ea87d5d
      Serge Hallyn authored
      The options are still supported in the lxc configuration file.
      However they are stored only in local variables in src/lxc/log.c,
      which can be read using two new functions:
      	int lxc_log_get_level(void);
      	const char *lxc_log_get_file(void);
      
      Changelog: jan 14:
       have lxc_log_init use lxc_log_set_file(), have lxc_log_set_file() take
       a const char *, and have it keep its own strdup'd copy of the filename.
      Signed-off-by: 's avatarSerge Hallyn <serge.hallyn@ubuntu.com>
  3. 13 Jan, 2013 1 commit
  4. 11 Jan, 2013 7 commits
  5. 10 Jan, 2013 2 commits
  6. 09 Jan, 2013 24 commits