Re: [lxc-devel] usernsselfmap

Serge Hallyn writes: > Quoting Eric W. Biederman (ebied...@xmission.com): > ... >> For what it's worth. If you are going to do a combined binary, and you >> are just going to worry about yourself. You don't have to fork to >> write /proc/self/uid_map with 0 $old_uid 1. > > Well, shoot! I figur

Re: [lxc-devel] usernsselfmap

Quoting Eric W. Biederman (ebied...@xmission.com): ... > For what it's worth. If you are going to do a combined binary, and you > are just going to worry about yourself. You don't have to fork to > write /proc/self/uid_map with 0 $old_uid 1. Well, shoot! I figured since we'd already unshared, o

Re: [lxc-devel] usernsselfmap

Kees Cook writes: > On Wed, Mar 6, 2013 at 2:25 PM, Serge Hallyn wrote: >> just to help play with user namespaces some more I pushed a C version >> of Eric's script for completely unprivileged use of user namespaces to >> https://code.launchpad.net/~serge-hallyn/+junk/nsexec and to the >> nsexec

Re: [lxc-devel] [PATCH] attach: handle apparmor transitions in !NEWNS cases

On 03/06/2013 02:41 PM, Serge Hallyn wrote: > If we're not attaching to the mount ns , then don't enter the > container's apparmor policy. Since we're running binaries from the host > and not the container, that actually seems the sane thing to do (besides > also the lazier thing). > > If we dont

[lxc-devel] Create LXC 0.8.0 rpm on/for Centos

Hi, I'm trying to build the rpm using the included spec file, but the compile is failing with a "You must install the AppArmor development package in order to compile lxc". I'm building it in/for CentOS and (AFAIK) there is no AppArmor development package for it. Is there any way to build th

[lxc-devel] usernsselfmap

Hey guys, just to help play with user namespaces some more I pushed a C version of Eric's script for completely unprivileged use of user namespaces to https://code.launchpad.net/~serge-hallyn/+junk/nsexec and to the nsexec package in ppa:serge-hallyn/userns-natty. Appending the code below as well

Re: [lxc-devel] [PATCH v2 0/3] lxc-attach improvements

Quoting Christian Seiler (christ...@iwakd.de): > Hi Serge, > > here are the updated versions of my patches (I also have to resend the > second one due to minor changes in the code from the first patch) that > implement the changes you requested. > > They can be found in the branch attach-fixes-1-

Re: [lxc-devel] [PATCH 3/3] lxc-attach: User namespaces: Use init's user & group id when attaching

Quoting Christian Seiler (christ...@iwakd.de): > When attaching to a container with a user namespace, try to detect the > user and group ids of init via /proc and attach as that same user. Only > if that is unsuccessful, fall back to (0, 0). > > Signed-off-by: Christian Seiler Thanks Christian!

Re: [lxc-devel] [PATCH 2/3] lxc-attach: Default to /bin/sh if shell cannot be determined or exec'd

Quoting Christian Seiler (christ...@iwakd.de): > If getpwuid() fails and also the fallback of spawning of a 'getent' > process, and the user specified no command to execute, default to > /bin/sh and only fail if even that is not available. This should ensure > that unless the container is *really*

Re: [lxc-devel] [PATCH 1/3] lxc-attach: Try really hard to determine login shell

Quoting Christian Seiler (christ...@iwakd.de): > If no command is specified, and using getpwuid() to determine the login > shell fails, try to spawn a process that executes the utility 'getent'. > getpwuid() may fail because of incompatibilities between the NSS > implementations on the host and in

[lxc-devel] [PATCH 2/3] lxc-attach: Default to /bin/sh if shell cannot be determined or exec'd

If getpwuid() fails and also the fallback of spawning of a 'getent' process, and the user specified no command to execute, default to /bin/sh and only fail if even that is not available. This should ensure that unless the container is *really* weird, no matter what, the user should always end up wi

[lxc-devel] [PATCH 3/3] lxc-attach: User namespaces: Use init's user & group id when attaching

When attaching to a container with a user namespace, try to detect the user and group ids of init via /proc and attach as that same user. Only if that is unsuccessful, fall back to (0, 0). Signed-off-by: Christian Seiler --- src/lxc/attach.c | 47 +++

[lxc-devel] [PATCH 1/3] lxc-attach: Try really hard to determine login shell

If no command is specified, and using getpwuid() to determine the login shell fails, try to spawn a process that executes the utility 'getent'. getpwuid() may fail because of incompatibilities between the NSS implementations on the host and in the container. Signed-off-by: Christian Seiler --- s

[lxc-devel] [PATCH v2 0/3] lxc-attach improvements

Hi Serge, here are the updated versions of my patches (I also have to resend the second one due to minor changes in the code from the first patch) that implement the changes you requested. They can be found in the branch attach-fixes-1-v2 at github,

[lxc-devel] [PATCH] attach: handle apparmor transitions in !NEWNS cases

If we're not attaching to the mount ns , then don't enter the container's apparmor policy. Since we're running binaries from the host and not the container, that actually seems the sane thing to do (besides also the lazier thing). If we dont' do this patch, then we will need to move the apparmor

Re: [lxc-devel] [PATCH 1/3] lxc-attach: Try really hard to determine login shell

Hi Serge, > Actually, I think it would be better to have lxc_attach_getpwuid() > become lxc_attach_getpwshell(), and change the caller a bit. > Would shorten up the code quite a bit. What do you think? Ok, will do. -- Christian --

Re: [lxc-devel] [PATCH 3/3] lxc-attach: User namespaces: Use init's user & group id when attaching

Hi Serge, > But also... you don't actually re-try with init_gid/init_uid of 0. > If lxc_attach_get_init_uidgid() set one of those to -1, then you'll > just fail here. No, because lxc_attach_get_init_uidgid doesn't modify them, see the code below the comment "only override arguments if we found s

Re: [lxc-devel] User namespaces

Quoting Dwight Engen (dwight.en...@oracle.com): > On Mon, 25 Feb 2013 20:26:21 -0800 > ebied...@xmission.com (Eric W. Biederman) wrote: ... > > For pty's since they only have the single device node. We can > > probably do kuid_has_mapping and kgid_has_mapping to see if we should > > have super use

Re: [lxc-devel] [PATCH 3/3] lxc-attach: User namespaces: Use init's user & group id when attaching

Quoting Christian Seiler (christ...@iwakd.de): > When attaching to a container with a user namespace, try to detect the > user and group ids of init via /proc and attach as that same user. Only > if that is unsuccessful, fall back to (0, 0). > --- > src/lxc/attach.c | 53 > +

Re: [lxc-devel] [PATCH 1/3] lxc-attach: Try really hard to determine login shell

Quoting Christian Seiler (christ...@iwakd.de): > If no command is specified, and using getpwuid() to determine the login > shell fails, try to spawn a process that executes the utility 'getent'. > getpwuid() may fail because of incompatibilities between the NSS > implementations on the host and in

Re: [lxc-devel] [PATCH 2/3] lxc-attach: Default to /bin/sh if shell cannot be determined or exec'd

Quoting Christian Seiler (christ...@iwakd.de): > If getpwuid() fails and also the fallback of spawning of a 'getent' > process, and the user specified no command to execute, default to > /bin/sh and only fail if even that is not available. This should ensure > that unless the container is *really*

Re: [lxc-devel] [PATCH 0/3] lxc-attach improvements

Quoting Christian Seiler (christ...@iwakd.de): > Hi Serge, > > here are my patches as emails to the lxc-devel list. The first patch > implements the getent(1) logic for trying much harder to determine the > correct login shell of the requested user (but only if getpwuid(3) > fails), the second pat

Re: [lxc-devel] [PATCH 1/3] lxc-attach: Try really hard to determine login shell

Quoting Christian Seiler (christ...@iwakd.de): > If no command is specified, and using getpwuid() to determine the login > shell fails, try to spawn a process that executes the utility 'getent'. > getpwuid() may fail because of incompatibilities between the NSS > implementations on the host and in