[lxc-devel] [PATCH] Set high byte of mac addresses for host veth devices to 0xfe

3] http://article.gmane.org/gmane.linux.kernel.containers.lxc.general/2796From e1b4779a89964ec43fa2bc5f76fafd965c89f73f Mon Sep 17 00:00:00 2001 From: Christian Seiler Date: Tue, 15 Nov 2011 18:53:53 +0100 Subject: [PATCH] Set high byte of mac addresses for host veth devices to 0xfe When used in conjunction with a bridg

Re: [lxc-devel] [PATCH] Set high byte of mac addresses for host veth devices to 0xfe

ixed patch. Thanks! Christian >From 0dce40ea882c560e0847a78058f962cd20fb4813 Mon Sep 17 00:00:00 2001 From: Christian Seiler Date: Tue, 15 Nov 2011 18:53:53 +0100 Subject: [PATCH] Set high byte of mac addresses for host veth devices to 0xfe When used in conjunction with a bridge, veth devices wit

Re: [lxc-devel] [PATCH] Set high byte of mac addresses for host veth devices to 0xfe

, nice catch. I've attached a fixed patch. I shouldn't be fixing patches so late at night, I only caught the first instance of this. Now I've attached a version which really fixes the problem. (Hopefully.) Sorry about the confusion. Christian >From 83f4ee619ed322be2845fd8ae988730cae2

[lxc-devel] lxc-attach and capabilities

Hi, Using kernel 3.1 and the LXC patches[*] to make lxc-attach work, if I drop capabilities such as CAP_NET_ADMIN from a container, if I access the container with lxc-attach, I have the full capabilities available in my host shell, not the limited capabilities of the container. Is this on purpose

Re: [lxc-devel] [GIT] lxc branch, master, updated. aa198728a83e7016cd02583349fce1f5b1a60c66

Hi there, > commit 49684c0b43d79310429b314e484ac2b1ab4ac6a1 > Author: Christian Seiler > Date: Tue Nov 15 18:53:53 2011 +0100 Thanks a lot for applying this. Unfortunately, you did not include the fixes for errno handling that came up later in the thread, where I resent the pa

[lxc-devel] [PATCH 3/3] Accept numeric values for capabilities to drop

lxc.cap.drop now also accepts numeric values for capabilities. This allows the user to specify capabilities LXC doesn't know about yet or capabilities that were not part of the kernel headers LXC was compiled against. --- src/lxc/conf.c | 17 + 1 files changed, 17 insertions(+),

[lxc-devel] [PATCH 2/3] Add CAP_SYSLOG and CAP_WAKE_ALARM to list of capabilities

--- src/lxc/conf.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/src/lxc/conf.c b/src/lxc/conf.c index 1a9851e..3fbc0eb 100644 --- a/src/lxc/conf.c +++ b/src/lxc/conf.c @@ -201,6 +201,12 @@ static struct caps_opt caps_opt[] = { { "setfcap", CAP_SET

[lxc-devel] [PATCH 1/3] Add function to determine CAP_LAST_CAP of the current kernel dynamically

The function lxc_caps_last_cap() determines CAP_LAST_CAP of the current kernel dynamically. It first tries to read /proc/sys/kernel/cap_last_cap. If that fails, because the kernel does not support this interface yet, it loops through all capabilities and tries to determine whether the current capab

[lxc-devel] [PATCH] Improve capability handling in LXC

Hi, I've attached patches that improve capability handling in LXC. I stumbled upon the issue that I wanted to deactivate "dmesg" from inside containers with a fairly recent kernel. Instead of dropping CAP_SYS_ADMIN, as it was the case with previous kernel versions, one is now supposed to drop CAP_

[lxc-devel] [PATCH 3/4] Add lxc_setup_for_attach function

lxc_setup_for_attach changes the context of the current running process in such a way that it matches that of the container it is supposed to attach to (personality, capabilities). --- src/lxc/conf.c | 16 src/lxc/conf.h |2 ++ 2 files changed, 18 insertions(+), 0 deletions(

[lxc-devel] [PATCH 4/4] lxc-attach: Change cgroup, personality and drop capabilities when attaching to container

lxc-attach is reworked so that it adds the newly attached process to the cgroup of the container, changes the personality of the process to that of the container and drops capabilities to those specified in the container configuration file. The latter can be overridden with a new option that allows

[lxc-devel] [PATCH 2/4] Add lxc_cgroup_attach function

This commit adds the lxc_cgroup_attach function that adds a pid to the tasks file of a specific cgroup in all subsystems. This is required for lxc-attach to be able to put newly started processes in the same cgroup as the container. --- src/lxc/cgroup.c | 47 +

[lxc-devel] [PATCH 1/4] Add missing 'extern' keyword to functions defined in cgroup.h

--- src/lxc/cgroup.h | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/lxc/cgroup.h b/src/lxc/cgroup.h index 188d948..31dd2de 100644 --- a/src/lxc/cgroup.h +++ b/src/lxc/cgroup.h @@ -26,9 +26,9 @@ #define MAXPRIOLEN 24 struct lxc_handler; -int lxc_cgroup_cre

[lxc-devel] [PATCH] lxc-attach: Consider cgroup, personality and capabilities when attaching processes to a container

Hi, As I didn't hear anything on this issue, I looked at it more closely and found found that not only are capabilities currently not dropped from withing lxc, but also the personality is not set correctly and the newly started process is not put in the correct cgroup (circumventing e.g. device re

Re: [lxc-devel] [PATCH 1/4] Add missing 'extern' keyword to functions defined in cgroup.h

Hi, > Note that "extern" keyword on function declarations has no > effect whatsoever. Yes, but I personally think it's good practice to always put it there, since it doesn't cause any harm either, because otherwise one may forget the keyword with variables, where it really matters. Also, lxc uses

Re: [lxc-devel] [PATCH] lxc-attach: Consider cgroup, personality and capabilities when attaching processes to a container

Hi Daniel, > thanks for your patches and your analysis. > > IMO, we have to take into account the process we want to attach could be > an admin task and this one may want to have the full permissions within > the container. Also that could be an external daemon with the same > permissions as t

[lxc-devel] [PATCH 4/9] cgroup: Make cgroup_attach a public function

lxc-attach needs to be able to attach a process to specific cgroup, so cgroup_attach is renamed to lxc_cgroup_attach and now also defined in the header file. --- src/lxc/cgroup.c |4 ++-- src/lxc/cgroup.h |1 + 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/src/lxc/cgroup.c

[lxc-devel] [PATCH v2] lxc-attach: Consider cgroups/personality/capabilities of container

Hi, This is the new version of my patch that implements the features discussed in the previous thread. - The current status of the container is now read from /proc/init_pid/*, where init_pid is the pid of the container's init process. - By default: * The attached process acquires the per

[lxc-devel] [PATCH 8/9] lxc-attach: Drop privileges when attaching to container unless requested otherwise

lxc-attach will now put the process that is attached to the container into the correct cgroups corresponding to the container, set the correct personality and drop the privileges. The information is extracted from entries in /proc of the init process of the container. Note that this relies on the

[lxc-devel] [PATCH 7/9] Move lxc_attach from namespace.c to attach.c and rename it to lxc_attach_to_ns

Since lxc-attach helper functions now have an own source file, lxc_attach is moved from namespace.c to attach.c and is renamed to lxc_attach_to_ns, because that better reflects what the function does (attaching to a container can also contain the setting of the process's personality, adding it to t

[lxc-devel] [PATCH 9/9] Add man page for lxc-attach

--- configure.ac |1 + doc/Makefile.am|1 + doc/lxc-attach.sgml.in | 189 doc/see_also.sgml.in |5 ++ 4 files changed, 196 insertions(+), 0 deletions(-) create mode 100644 doc/lxc-attach.sgml.in diff --git a/config

[lxc-devel] [PATCH 5/9] Add lxc_config_parse_arch to parse architecture strings

Add the function lxc_config_parse_arch that parses an architecture string (x86, i686, x86_64, amd64) and returns the corresponding personality. This is required for lxc-attach, which accepts architectures independently of lxc.arch. The parsing of lxc.arch now also uses the same function to ensure c

[lxc-devel] [PATCH 3/9] Enable get_cgroup_mount to search for mount points satisfying multiple subsystems at once

lxc-attach functionality reads /proc/init_pid/cgroup to determine the cgroup of the container for a given subsystem. However, since subsystems may be mounted together, we want to be on the safe side and be sure that we really find the correct mount point, so we allow get_cgroup_mount to check for *

[lxc-devel] [PATCH 1/9] Add missing 'extern' keyword to functions defined in cgroup.h

--- src/lxc/cgroup.h | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/lxc/cgroup.h b/src/lxc/cgroup.h index 188d948..31dd2de 100644 --- a/src/lxc/cgroup.h +++ b/src/lxc/cgroup.h @@ -26,9 +26,9 @@ #define MAXPRIOLEN 24 struct lxc_handler; -int lxc_cgroup_cre

[lxc-devel] [PATCH 6/9] Add attach.[ch]: Helper functions for lxc-attach

The following helper functions for lxc-attach are added to a new file attach.c: - lxc_proc_get_context_info: Get cgroup memberships, personality and capability bounding set from /proc for a given process. - lxc_proc_free_context_info: Free the data structure responsible - lxc_attach_proc_to_c

[lxc-devel] [PATCH 2/9] Add missing double-include #ifndef/#define/#endif to confile.h

--- src/lxc/confile.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/src/lxc/confile.h b/src/lxc/confile.h index 6698fb2..f415e55 100644 --- a/src/lxc/confile.h +++ b/src/lxc/confile.h @@ -21,6 +21,9 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 0211

Re: [lxc-devel] [PATCH v2] lxc-attach: Consider cgroups/personality/capabilities of container

Hi there, > This is the new version of my patch that implements the features > discussed > in the previous thread. > > - The current status of the container is now read from > /proc/init_pid/*, >where init_pid is the pid of the container's init process. > - By default: > * The attached

Re: [lxc-devel] [PATCH v2] lxc-attach: Consider cgroups/personality/capabilities of container

Hi Daniel, > your patchset is in my tree. I will do some tests and push it. Thanks! Regards, Christian -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but clou

[lxc-devel] [PATCH] Add lxc-net tool

Add a tool that switches context to enter the network namespace and then execute an arbitrary command. Since we don't change mount / pid namespaces, this allows the user to use the host's networking tools such as iputils, iptables, netstat to query / configure the container from the outside. This m

Re: [lxc-devel] [PATCH] Add lxc-net tool

Hi, > Until lxc-attach is extended (Serge Hallyn took that action item), Extending lxc-attach would also be fine by me - is anybody already working on this? If not, I'd be willing to do that. > I suggest using this very simple script to switch network namespaces: > http://paste.ubuntu.com/992744

Re: [lxc-devel] [PATCH] Add lxc-net tool

Hi again, >> Extending lxc-attach would also be fine by me - is anybody already >> working on this? If not, I'd be willing to do that. > > It's on the todo list at the moment, I don't believe anyone is > actively working on it at the moment. > > So if you want to do it, it'd be much appreciated.

Re: [lxc-devel] [PATCH] Add lxc-net tool

Hi, >> - they unshare the mount namespace and remount /sys - apparently, in >>contrast to /proc, which depends on the current process's context, >>/sys depends on the context of the process mounting it > > Both actually depend on the context of the process mounting it. If you > do "lxc-

[lxc-devel] [PATCH] Add option to lxc-attach to select specific namespaces

This patch adds the -s/--namespaces option to lxc-attach that works analogously to lxc-unshare, allowing the user to select the namespaces the process should be attached to. Signed-off-by: Christian Seiler Cc: Stéphane Graber Cc: Daniel Lezcano Cc: Serge Hallyn --- doc/lxc-attach.sgml.in

[lxc-devel] [PATCH] [trivial] Add files to .gitignore

--- .gitignore |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/.gitignore b/.gitignore index 8c84a23..1171613 100644 --- a/.gitignore +++ b/.gitignore @@ -34,7 +34,12 @@ templates/lxc-altlinux templates/lxc-sshd templates/lxc-busybox templates/lxc-archlinux +templ

Re: [lxc-devel] [PATCH] Add option to lxc-attach to select specific namespaces

>> +int flags[] = { CLONE_NEWPID, CLONE_NEWNS, CLONE_NEWNET, CLONE_NEWIPC, >> CLONE_NEWUTS }; > ... >> -static char *namespaces_list[] = { >> -"MOUNT", "PID", "UTSNAME", "IPC", >> -"USER", "NETWORK" >> -}; >> -static int cloneflags_list[] = { >> -CLONE_NEWNS, CLONE_NEWPID, CLONE_NE

[lxc-devel] [PATCH v2 1/2] Add option to lxc-attach to select specific namespaces

ntly, user namespaces will be skipped (without having lxc-attach fail, unlike for other namespaces) if the kernel lacks support. Signed-off-by: Christian Seiler Cc: Stéphane Graber Cc: Daniel Lezcano Cc: Serge Hallyn --- doc/lxc-attach.sgml.in | 99 +-

[lxc-devel] [PATCH v2 0/2] Partial namespaces for lxc-attach

Hi Serge, I've updated my patch for lxc-attach in order to reflect your comments: The ordering of the flags is now consistent across the source code and I've added CLONE_NEWUSER to the list of flags. The only thing I wasn't clear about was what the file in /proc/pid/ns will be called once setns()

[lxc-devel] [PATCH v2 2/2] lxc-attach: Add -R option to remount /sys and /proc when only partially attaching

ty to additionally unshare the mount namespace (when it is not being attached) and remount /sys and /proc in order for those filesystems to properly reflect the container's context even when only attaching to some of the namespaces. Signed-off-by: Christian Seiler Cc: Stéphane Graber Cc: Daniel L

Re: [lxc-devel] [PATCH v2 1/2] Add option to lxc-attach to select specific namespaces

Hi Serge, > Note that for now the same thing will happen with pid. I don't think > CLONE_NEWUSER needs to be special cased. Likewise, someone may want > to use this lxc on an older kernel without any setns support at all. I'm not sure this is wise: Currently, kernel 3.0 supports all namespaces

Re: [lxc-devel] [PATCH v2 1/2] Add option to lxc-attach to select specific namespaces

Hi Serge, > That sounds good, but then to do it right the "which namespaces were > unshared by the container" shouldn't be hardcoded in. Unfortunately, > without the /proc/self/ns/ links there's no way to tell, so we can't > answer your question. > > So I think we should do your point 1, but not

Re: [lxc-devel] [PATCH v2 1/2] Add option to lxc-attach to select specific namespaces

Hi Serge, >> What about if we update the command interface to add an additional >> command along the lines of LXC_COMMAND_GET_NSFLAGS or similar, which >> returns the bitmask of CLONE_* used for starting the container? Then >> we would have the logic: > > That works fine for persistent containers

Re: [lxc-devel] [PATCH v2 1/2] Add option to lxc-attach to select specific namespaces

Hi Serge, >> >>What about if we update the command interface to add an additional >> >>command along the lines of LXC_COMMAND_GET_NSFLAGS or similar, >> which >> >>returns the bitmask of CLONE_* used for starting the container? >> Then >> >>we would have the logic: >> > >> >That works fine for p

[lxc-devel] [PATCH v3 4/6] lxc-unshare: Move functions to determine clone flags from command line options to namespace.c

In order to be able to reuse code in lxc-attach, the functions lxc_namespace_2_cloneflag and lxc_fill_namespace_flags are moved from lxc_unshare.c to namespace.c. Signed-off-by: Christian Seiler Cc: Daniel Lezcano Cc: Serge Hallyn --- src/lxc/lxc_unshare.c | 45

[lxc-devel] [PATCH v3 0/6] Partial namespaces for lxc-attach

Hi there, this is my third (and hopefully final :)) patch series for partial namespaces in lxc-attach. I've made the following changes to the previous versions: - Split up the patches a tiny bit more, should make the changes a bit clearer. - I actually encountered a problem with pid namespa

[lxc-devel] [PATCH v3 1/6] lxc-start: Add command to retrieve the clone flags used to start the container.

Add the LXC_COMMAND_CLONE_FLAGS that retrieves the flags passed to clone(2) when the container was started. This allows external programs to determine which namespaces the container was unshared from. Signed-off-by: Christian Seiler Cc: Daniel Lezcano Cc: Serge Hallyn --- src/lxc/commands.c

[lxc-devel] [PATCH v3 2/6] lxc-attach: Remodel cgroup attach logic and attach to namespaces again in parent process

us to open all the tasks files in lxc_attach, then call setns(), then fork, in the child process close them completely and in the parent process just write the pid of the child process to all those fds. Signed-off-by: Christian Seiler Cc: Daniel Lezcano Cc: Serge Hallyn --- src/lxc/cgr

[lxc-devel] [PATCH v3 3/6] lxc-attach: Detect which namespaces to attach to dynamically

Use the command interface to contact lxc-start to receive the set of flags passed to clone() when starting the container. This allows lxc-attach to determine which namespaces were used for the container and select only those to attach to. Signed-off-by: Christian Seiler Cc: Daniel Lezcano Cc

[lxc-devel] [PATCH v3 5/6] lxc-attach: Add -s option to select namespaces to attach to

x27;s (and not the container's) network tools to reconfigure the network of the container. Signed-off-by: Christian Seiler Cc: Daniel Lezcano Cc: Serge Hallyn --- doc/lxc-attach.sgml.in | 98 +-- src/lxc/lxc_attach.c | 20 +- 2 fil

[lxc-devel] [PATCH v3 6/6] lxc-attach: Add -R option to remount /sys and /proc when only partially attaching

ty to additionally unshare the mount namespace (when it is not being attached) and remount /sys and /proc in order for those filesystems to properly reflect the container's context even when only attaching to some of the namespaces. Signed-off-by: Christian Seiler Acked-by: Serge Hallyn Cc: Dani

Re: [lxc-devel] [PATCH v3 6/6] lxc-attach: Add -R option to remount /sys and /proc when only partially attaching

Hi Serge, > Note there is no reason to resend this patch for this, Actually, there were some trivial changes here due to patch #2, which reordered some code in lxc_attach.c - that's why I resent it. Now it should be trivial to apply all of the 6 patches to the current master branch, before you'd

[lxc-devel] Shutting down containers properly

Hi, Currently, lxc-stop sends SIGKILL to the init process of the container, which causes all the other processes in the container to also receive a SIGKILL. I don't think that is a good course of action, since sending SIGKILL to for example a database server can lead to potential data loss. A muc

Re: [lxc-devel] Shutting down containers properly

Hi, > my lxc management script uses lxc-stop just for an emergency action > called "fored-stop" and it will be also applied, if a normal "stop" > (alias "halt") action will timeout after 5min. For this normal > shutdown (or reboot) of a container, I'm sending just a SIGPWR (or > SIGINT) to the con

Re: [lxc-devel] Shutting down containers properly

Hi, > Have you looked at the lxc-shutdown script we have in Ubuntu and the > integration we have with upstart? No, not yet, but I'll look at it later. > lxc-shutdown sends two different signals: > reboot => SIGINT > shutdown => SIGPWR > > These are caught by upstart and will trigger a clean re

Re: [lxc-devel] [GIT] lxc branch, master, updated. 60a742e0afd34e02299f64536df35116d68d888d

Hi there, I just wanted to ask what happend to my patches that improved upon attach/unshare? Final version: http://thread.gmane.org/gmane.linux.kernel.containers.lxc.devel/1408/focus=1436 Thanks in advance! Regards, Christian

Re: [lxc-devel] [PATCH] lxc-wait: Add timeout option

Hi Serge, > My github tree is my staging tree for things I'd like to have merged into > lxc.sf.net, so hopefully when Daniel has time again he'll take it. (I > posted it to my tree after the last time Daniel merged) Btw. could you also add my patchset under http://thread.gmane.org/gmane.linux.k

[lxc-devel] [PATCH v3 RESENT] Partial namespaces for lxc-attach

Serge, Here you go, I've rebased the patches against Daniel's current master branch, so that they properly apply. Christian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's securi

[lxc-devel] [PATCH 5/6] lxc-attach: Add -s option to select namespaces to attach to

x27;s (and not the container's) network tools to reconfigure the network of the container. Signed-off-by: Christian Seiler Cc: Daniel Lezcano Cc: Serge Hallyn --- doc/lxc-attach.sgml.in | 98 +-- src/lxc/lxc_attach.c | 20 +- 2 fil

[lxc-devel] [PATCH 2/6] lxc-attach: Remodel cgroup attach logic and attach to namespaces again in parent process

us to open all the tasks files in lxc_attach, then call setns(), then fork, in the child process close them completely and in the parent process just write the pid of the child process to all those fds. Signed-off-by: Christian Seiler Cc: Daniel Lezcano Cc: Serge Hallyn --- src/lxc/cgr

[lxc-devel] [PATCH 3/6] lxc-attach: Detect which namespaces to attach to dynamically

Use the command interface to contact lxc-start to receive the set of flags passed to clone() when starting the container. This allows lxc-attach to determine which namespaces were used for the container and select only those to attach to. Signed-off-by: Christian Seiler Cc: Daniel Lezcano Cc

[lxc-devel] [PATCH 4/6] lxc-unshare: Move functions to determine clone flags from command line options to namespace.c

In order to be able to reuse code in lxc-attach, the functions lxc_namespace_2_cloneflag and lxc_fill_namespace_flags are moved from lxc_unshare.c to namespace.c. Signed-off-by: Christian Seiler Cc: Daniel Lezcano Cc: Serge Hallyn --- src/lxc/lxc_unshare.c | 45

[lxc-devel] [PATCH 1/6] lxc-start: Add command to retrieve the clone flags used to start the container.

Add the LXC_COMMAND_CLONE_FLAGS that retrieves the flags passed to clone(2) when the container was started. This allows external programs to determine which namespaces the container was unshared from. Signed-off-by: Christian Seiler Cc: Daniel Lezcano Cc: Serge Hallyn --- src/lxc/commands.c

[lxc-devel] [PATCH 6/6] lxc-attach: Add -R option to remount /sys and /proc when only partially attaching

ty to additionally unshare the mount namespace (when it is not being attached) and remount /sys and /proc in order for those filesystems to properly reflect the container's context even when only attaching to some of the namespaces. Signed-off-by: Christian Seiler Acked-by: Serge Hallyn Cc: Dani

[lxc-devel] [PATCH] Add mechanism for container to notify host about end of boot

mple to just add a new value for the lxc.notification.type option. Signed-off-by: Christian Seiler Cc: Serge Hallyn Cc: Guido Jäkel --- src/lxc/Makefile.am|1 + src/lxc/conf.c |8 + src/lxc/conf.h |3 + src/lxc/confile.c | 34

Re: [lxc-devel] [PATCH] Add mechanism for container to notify host about end of boot

> I like the idea but haven't looked at the implementation yet as the > patch is really quite large. Quickly scanning through I briefly noticed > that the copyright headers for the new files are wrong (refer to IBM and > Daniel instead of Christian). I just copy&pasted them from the other files, m

[lxc-devel] Fwd: Re: [PATCH] Add mechanism for container to notify host about end of boot

forwarding to the list because I forgot to use reply-to-all - sorry. --- Begin Message --- >> If we want to have a back-channel, we'd need a socket, which makes just >> doing echo RUNNING > /dev/lxc-notify impossible, you'd need a special >> program for that. Having the template scripts dump an ad

Re: [lxc-devel] [PATCH] Add mechanism for container to notify host about end of boot

>> If we want to have a back-channel, we'd need a socket, which makes >> just >> doing echo RUNNING > /dev/lxc-notify impossible, you'd need a >> special >> program for that. Having the template scripts dump an additional >> script >> or upstart job or systemd unit file or whatever in the contai

Re: [lxc-devel] [PATCH] Add mechanism for container to notify host about end of boot

> I'm very pleased about the discussion and efforts to implement such a > feature because I already have asked for it in former times. In the > one hand, this fifo approach may be used for more than the current > task. But in the other hand, it's seems to need a bunch of > dependencies. You mean t

Re: [lxc-devel] [PATCH] Add mechanism for container to notify host about end of boot

> I must admit the details aren't worked out, but the rough idea was > something like the following. On the host have a directory per > container, in which the socket is setup > >/var/lib/systemd/container/ > > And bind '/var/lib/systemd/containerXXX' into the container in some > location,

Re: [lxc-devel] [PATCH] Add mechanism for container to notify host about end of boot

Hi, > It is a bit weird to bind mount this fifo. IMHO, a lot of low-level stuff appears to be at first glance, until you understand the reasoning behind it. Bind-mounting non-directories is actually used a lot in namepsaces. For example, if you want to keep a network namespace around after the

Re: [lxc-devel] [PATCH 1/2] fix trivial off by one error

Hi, Just a heads up: > Since the if uses >=, the - 1 is not needed and the MAXFDS'th > entry in the fds array can be used. This was from part of one of my patches regarding lxc-attach and it is NOT an off-by-one error, it is meant to be this way. The problem is that the array has to be traversed

Re: [lxc-devel] [PATCH 1/2] fix trivial off by one error

Hi, > Do you think mallocing an fd_set and using FD_SET() and friends > would be better? The (dispose|finish) loops would visit FD_SETSIZE bits > with an FD_ISSET() test, which is more work than you have currently > with the early out, but we would probably save on the initialization > with FD_ZER

Re: [lxc-devel] [PATCH] Add mechanism for container to notify host about end of boot

Hi there, I've now updated my patch, there are now the following changes, partially based on feedback from this list, partially from sorting things in my head a bit. - socket instead of a FIFO - is now in /run instead of /dev - parent directories of socket inside container are automatically

[lxc-devel] [PATCH v2] Add mechanism for container to notify host about end of boot

the container, so if somebody types 'shutdown -h now' in the container, the status gets updated immediately. The mechanism is designed to be extensible, i.e. commands other than 'status' may be supported at a later point, if other needs arise for the communication between inside

Re: [lxc-devel] [PATCH] Add mechanism for container to notify host about end of boot

Hi, >> - is now in /run instead of /dev > > I don't think that part's going to work... Most distros mount /run as > tmpfs at boot time which will hide anything you're putting in there > before boot. Hmmm, that is indeed a problem... Do you have any suggestions? Or should we just keep it in /dev

[lxc-devel] [PATCH v2.1] Add mechanism for container to notify host about end of boot

the container, so if somebody types 'shutdown -h now' in the container, the status gets updated immediately. The mechanism is designed to be extensible, i.e. commands other than 'status' may be supported at a later point, if other needs arise for the communication between inside a

Re: [lxc-devel] [PATCH] Add mechanism for container to notify host about end of boot

Hi, >> I think /dev is the safest at the moment. Arguably it's wrong as it's >> not an actual device node, but it's the only directory that lxc already >> requires all distros not to mess with (or we wouldn't have working >> console, tty, ...). > > What are some other alternatives? > > We could

[lxc-devel] [PATCH] [trivial] lxc-ls: Scan cgroup mount points from fstype and not device

lxc-ls --active now scans mount points that have the 'cgroup' filesystem type and not the 'cgroup' device name (which is ignored anyway and may be anything). Signed-off-by: Christian Seiler Cc: Serge Hallyn --- src/lxc/lxc-ls.in |2 +- 1 files changed, 1 insertions(+),

[lxc-devel] [PATCH] Multiple IP addresses: add them in the correct order

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: Christian Seiler --- src/lxc/confile.c |4 ++-- 1 files

Re: [lxc-devel] [PATCH 1/1] lxc_attach: fix break with user namespaces (v2)

Hi Serge, Just a few quick comments because I'm very interested in the lxc-attach utility: > + ret = lxc_cgroup_prepare_attach(my_args.name, > &cgroup_data); > + if (ret < 0) { > + ERROR("failed to prepare attaching to cgroup");

Re: [lxc-devel] [PATCH 1/1] lxc_attach: fix break with user namespaces (v2)

Hi Serge, > Would you care to update the patch along these lines? Will do, but it will take me a few days time, since I have to set up an environment where I can test user namespaces first. Regards, Christian -- Master

[lxc-devel] [PATCH 0/2] lxc_attach and user namespaces

As discussed earlier on this list with Serge, here is my first set of patches that fixes lxc_attach to user namespaces. The first patch is bascially Serge's patch v2 with the following changes: - use socketpair() instead of pipes because we need two-way communication; before we exec() we need

[lxc-devel] [PATCH 2/2] lxc_attach: Clean up cgroup attaching code

Since lxc_attach now works with two fork()s anyway due to user namespaces, the code for attaching to cgroups can be simplified again. This patch removes the prepare/finish/dispose functions for attaching to cgroups and just keeps the lxc_cgroup_attach function. --- src/lxc/cgroup.c | 154 ++-

[lxc-devel] [PATCH 1/2] lxc_attach: fix break with user namespaces (v3)

smarter, but for now this allows lxc-attach to work. Signed-off-by: Christian Seiler --- src/lxc/lxc_attach.c | 178 ++ 1 files changed, 150 insertions(+), 28 deletions(-) diff --git a/src/lxc/lxc_attach.c b/src/lxc/lxc_attach.c index e1511ef

Re: [lxc-devel] [PATCH 2/2] lxc_attach: Clean up cgroup attaching code

Hi Serge, > (Note - no signed-off-by in this patch. How are you generating them? > I'd recommend either using git-send-email, or get format-patch...) Oh, I didn't know git format-patch had a --signoff option, I always added the line manually when committing and this time I just forgot it. ;-) >

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

thout a command argument, this makes the default behavior of lxc-attach a lot more robust. Signed-off-by: Christian Seiler --- src/lxc/lxc_attach.c | 22 -- 1 file changed, 16 insertions(+), 6 deletions(-) diff --git a/src/lxc/lxc_attach.c b/src/lxc/lxc_attach.c index 1f

[lxc-devel] [PATCH 3/3] lxc-attach: Allow the user to request uid/gid when attaching

This patch implements the -u and -g options for lxc-attach that allows the user to ask for a specific user and group id when attaching to a container. NOTE: DO NOT APPLY THIS PATCH JUST YET, THERE ARE SECURITY IMPLICATIONS THAT HAVE TO BE CONSIDERED BEFORE DOING SO. THIS IS JUST A DRAFT. --- src/

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

Hi, I've attached three additional patches for possible improvements to lxc-attach. The first two I think should be applied directly, they do the following: 1) Create a sane fallback to /bin/sh if it is impossible to detect the container's shell because of incompatible nss implementations

[lxc-devel] [PATCH 2/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 | 53

[lxc-devel] lxc-attach: NSS handling

Hi there, I've run into the problem multiple times now that lxc-attach can't detect the default shell of my current user properly, since the NSS implementations of host and container are incompatible. One of the patches I just sent to the list mitigates that by having a fallback - use /bin/sh. Th

[lxc-devel] Fwd: Re: lxc-attach: NSS handling

Sorry, I forgot to post to the list... Original-Nachricht Betreff: Re: [lxc-devel] lxc-attach: NSS handling Datum: Tue, 05 Mar 2013 00:01:55 +0100 Von: Christian Seiler An: Serge Hallyn Hi Serge, > So if you resend the patchset, I'd suggest this patch first, the >

[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 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: Christ

[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). --- src/lxc/attach.c | 53 ++ src/lxc/attach.h |

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

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 patch uses /bin/sh as a fallback if even that fails and the th

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] [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 --

[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 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: Christ

[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 2/3] lxc-attach: Default to /bin/sh if shell cannot be determined or exec'd

ays end up with a shell when calling lxc-attach with no further arguments. Signed-off-by: Christian Seiler --- src/lxc/lxc_attach.c | 16 +++- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/src/lxc/lxc_attach.c b/src/lxc/lxc_attach.c index c129eb0..711e1de 100644 ---

  1   2   3   >