Re: [lxc-devel] [PATCH] lxc-attach: elevate specific privileges

them > are elevated. > > Signed-off-by: Nikola Kotur Acked-By: Christian Seiler -- Christian -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation.

Re: [lxc-devel] [PATCH] lxc-attach: elevate specific privileges

Hi there, > And if you have a bit of time I'd appreciate if you could explain why > should we elevate privileges for attaching to specific namespace? > Seems > to me that it is unrelated, since I should be able to enter NETWORK > ns > while not elevating cgroup, for example? Since I added those

Re: [lxc-devel] CLONE_PARENT after setns(CLONE_NEWPID)

Hi there, > Having used bash as an init process I know it can handle unexpeted > children. However using CLONE_PARENT in this way still seems a little > dodgy. Or am I misunderstanding why you are using CLONE_PARENT? Since I (re)wrote that part of LXC, I should perhaps clarify how that is used:

Re: [lxc-devel] [PATCH 1/1] lxc/conf.c Heuristic determination of autodev condition...

Hi there, > The initial heuristic, in this case, is the existence > of /etc/systemd/system in the container to enable autodev. This is > the > heuristic used in the lxc-fedora template but it applicable to all > systemd containers, as far as I can determine. Just a quick note about the specific

[lxc-devel] [RFC] yet another rootfs pinning change

Hi, I'm attaching a patch that makes additional chanes to the rootfs pinning mechanism. It can also be found under: This patch implements things that were floating around in discussions earlier. I know it is still in flux of how to best handle

[lxc-devel] [PATCH] rootfs pinning: make file hidden, don't delete it, encode pid

: Christian Seiler --- src/lxc/conf.c | 24 +++- src/lxc/conf.h |2 +- src/lxc/start.c | 10 +- src/lxc/start.h |1 + 4 files changed, 26 insertions(+), 11 deletions(-) diff --git a/src/lxc/conf.c b/src/lxc/conf.c index ecbcf41..4cd9462 100644 --- a/src

Re: [lxc-devel] [PATCH 1/4] Automatic mounts: improvements for /proc and /sys

Hi Serge, > My 3.2, 3.8 and 3.11 kernels all behave the same: > > serge@sergeh1:~$ sudo mount -t tmpfs tmpfs /mnt > serge@sergeh1:~$ sudo mount --bind /mnt /mnt2 > serge@sergeh1:~$ sudo mount -o remount,ro /mnt2 > serge@sergeh1:~$ sudo touch /mnt/a > serge@sergeh1:~$ mount | grep /mnt > tmpfs on /

Re: [lxc-devel] [PATCH 1/4] Automatic mounts: improvements for /proc and /sys

Hi Serge, >> Yes, I see what you mean, but this is definitely a change in the >> behaviour of the kernel compared to previous versions. And that >> also means that (see other thread) bind-mounting a rootfs onto >> itself will not prevent a container from remounting the filesystem >> readonly on sh

Re: [lxc-devel] [PATCH 1/4] Automatic mounts: improvements for /proc and /sys

Hi Serge, >> +/* Read-only bind-mounting... In older kernels, doing that >> required >> + * to do one MS_BIND mount and then MS_REMOUNT|MS_RDONLY the >> same >> + * one. According to mount(2) manpage, MS_BIND honors MS_RDONLY >> from >> + * kernel

Re: [lxc-devel] [lxc/lxc] b65330: split up lxc_cgroup_load_meta2

Hi there, > The result seems easier to reason about. I agree, thanks! > A question I had, is, should > the kernel_subsystems ** be freed in the success case? I assumed it > was > being used elsewhere but I can't find where. Currently it is only > being > freed in the error case. I suspect

Re: [lxc-devel] [RFC] rootfs pinning

Hi there, > No. There's a change there, all right, and thank you for reminding > me > of that, but (afaik) it's NOT in the kernel itself. It's a mount > option. It's that bloody MS_SHARED option and, to a lessor extent, > MS_SLAVE option that are behind how those things are propagated. > MS_SH

Re: [lxc-devel] [RFC] rootfs pinning

Hi there, >> Yep, we discussed this at Plumbers and I think it's really the way >> to >> go, basically remove all of that fs pinning code and just do a >> bind-mount of the rootfs on itself in the container's mountns before >> starting it. > >> That way if the container decideds to remount / ro a

[lxc-devel] [PATCH 1/4] Automatic mounts: improvements for /proc and /sys

Improve lxc.mount.auto code: allow the user to specify whether to mount certain things read-only or read-write. Also make the code much more easily extensible for the future. Signed-off-by: Christian Seiler --- src/lxc/conf.c| 144 + src

[lxc-devel] [PATCH 2/4] Automatic mounting: write lxc.mount.auto in write_config

Signed-off-by: Christian Seiler --- src/lxc/confile.c | 23 +++ 1 file changed, 23 insertions(+) diff --git a/src/lxc/confile.c b/src/lxc/confile.c index 04b8e57..0d5cf1f 100644 --- a/src/lxc/confile.c +++ b/src/lxc/confile.c @@ -2002,6 +2002,29 @@ void write_config(FILE

[lxc-devel] [PATCH 0/4] Automatic mounting improvements

Hi there, I've attached the automatic mounting improvements that were discussed in the thread The patches are against current github master and I've also pushed them to my github:

[lxc-devel] [PATCH 3/4] Automatic mounting: add more ways to mount the cgroup filesystem

that mounts the entire cgroup tree to the corresponding directories. ro/rw/mixed also apply here. Signed-off-by: Christian Seiler --- src/lxc/cgroup.c | 87 +++--- src/lxc/cgroup.h |2 +- src/lxc/conf.c |2 +- 3 files changed, 71 inser

[lxc-devel] [PATCH 4/4] Automatic mounting: document options in lxc.conf(5) manpage

Signed-off-by: Christian Seiler --- doc/lxc.conf.sgml.in | 99 ++ 1 file changed, 99 insertions(+) diff --git a/doc/lxc.conf.sgml.in b/doc/lxc.conf.sgml.in index dc416e8..d904b56 100644 --- a/doc/lxc.conf.sgml.in +++ b/doc/lxc.conf.sgml.in

Re: [lxc-devel] Change rootfs pinning mechnism

Hi there, > Concur on the revert. > > What is really gained by deleting that file? I agree with the basic > idea of moving and renaming that file to hold the mount open but, are > we > really that worried that someone will inadvertently delete that file? > It shouldn't be a security issue and I

Re: [lxc-devel] Change rootfs pinning mechnism

Hi there, > I would suggest to add a config switch to choose between early > unlinking and removing at shutdown. Because I'm using a setup where > the rootfs are shared between several hosts and an container may be > run on any of it. For this usecase, the rootfs pinmarker is a (not > perfect but)

Re: [lxc-devel] [PATCH 3/4] cgroup: Add lxc_setup_mount_cgroup to setup /sys/fs/cgroup inside the container

Hi Serge, > Ah, no, mountall just gets upset about some forced readonly > mounts. lxc.mount.auto = proc always worked for me. If I do > > - r = mount("sysfs", path, "sysfs", MS_RDONLY, NULL); > + r = mount("sysfs", path, "sysfs", 0, NULL); > - mount(NULL, path,

Re: [lxc-devel] [PATCH 3/4] cgroup: Add lxc_setup_mount_cgroup to setup /sys/fs/cgroup inside the container

Hi Serge, Am 12.09.2013 16:43, schrieb Serge Hallyn: > Quoting Christian Seiler (christ...@iwakd.de): >> Add funbction to mount cgroup filesystem hierarchy into the >> container, >> allowing only access to the parts that the container should have >> access >> to

[lxc-devel] [PATCH] Change rootfs pinning mechnism

: Christian Seiler --- src/lxc/conf.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/src/lxc/conf.c b/src/lxc/conf.c index 5f9ae87..291ea6f 100644 --- a/src/lxc/conf.c +++ b/src/lxc/conf.c @@ -670,9 +670,10 @@ static int mount_rootfs_block(const char *rootfs, const

Re: [lxc-devel] [PATCH 3/4] cgroup: Add lxc_setup_mount_cgroup to setup /sys/fs/cgroup inside the container

Hi Serge, >> Would you agree? > > Yup, sounds good. This email should probably be cut-pasted into the > lxc.conf man page then :) > > Should I apply the patch 4/4 as it stands now and the rest can be a > separate patch? > > Oh, one other thing is lxc.mount.auto needs to be added to > write_con

Re: [lxc-devel] [PATCH 3/4] cgroup: Add lxc_setup_mount_cgroup to setup /sys/fs/cgroup inside the container

Hi Serge, >> I could get behind the following: >> >>proc- always read-write (no harm AFAICT) >>sys - default: read-only >>sys:rw - read-write >>sys:ro - explicit read-only >>cgroup:ro - completely ro (including paths) >>cgroup

[lxc-devel] [RFC] rootfs pinning

Hi there, just a quick question: currently, rootfs is pinned with a .hold file in the parent directory (which btw. does not help against file systems that are already mounted on the host but directly in the rootfs directory). The problem with the .hold file is that it doesn't make the directory ne

Re: [lxc-devel] [PATCH] cgroup: re-introduce ns cgroup support

Hi Serge, >> cgroups and have a separate function for the ns cgroup entries? Then > > Makes perfect sense to me to do so, yes. Since you didn't respond and I was in the mood to finish it, I assumed that you'd be OK with that, see my other set of patches for automatic cgroup mounting. -- Christia

Re: [lxc-devel] [PATCH] move monitor-fifo and monitor-sock to /run

Hi Serge, >> Only problem: it's not thread-safe... And in contrast to openat() or the > > We could just do process_lock() around the whole shebang if we had to. > > But I can't think offhand of any reason why we'd ever need to go from > the socketname back to the lxcpath, so using md5sum really

Re: [lxc-devel] [PATCH] cgroup: re-introduce ns cgroup support

Hi again, I was just looking at how to best implement the cgroup mount hook. Problem now is that the easiest way would be just to create the cgroup before the clone() (enter is done afterwards anyway) so that the client has access to handler->pid. Unfortunately, handler->pid is needed for the ns c

[lxc-devel] [PATCH 4/4] Support for automatic mounting of filesystems

he logic here is to bind-mount /dev/null over /proc/sysrq-trigger, so that that cannot happen. This obviously only protects fully if CAP_SYS_ADMIN is not available inside the container (otherwise that bind-mount could be removed). Signed-off-by: Christian Seiler --- src/lxc/conf.c

[lxc-devel] [PATCH 0/4] Automatic cgroup mounting support

Hi, I've implemented support to automatically mount the cgroup hierarchy into the container as discussed on the mailing list. On that occasion, I also added automatic mounting support for /sys and /proc. All is controlled by the new lxc.mount.auto option that accepts a list of parameters, e.g. 'lx

[lxc-devel] [PATCH 3/4] cgroup: Add lxc_setup_mount_cgroup to setup /sys/fs/cgroup inside the container

Add funbction to mount cgroup filesystem hierarchy into the container, allowing only access to the parts that the container should have access to, but none else. Signed-off-by: Christian Seiler --- src/lxc/cgroup.c | 127 ++ src/lxc/cgroup.h

[lxc-devel] [PATCH 1/4] utils: Add lxc_append_paths to join two paths.

Signed-off-by: Christian Seiler --- src/lxc/utils.c | 19 +++ src/lxc/utils.h |1 + 2 files changed, 20 insertions(+) diff --git a/src/lxc/utils.c b/src/lxc/utils.c index 2e66585..78b234d 100644 --- a/src/lxc/utils.c +++ b/src/lxc/utils.c @@ -658,6 +658,25 @@ char

[lxc-devel] [PATCH 2/4] cgroup: Split legacy 'ns' cgroup handling off from main cgroup handling

fter clone. Signed-off-by: Christian Seiler --- src/lxc/cgroup.c | 61 +++--- src/lxc/cgroup.h |3 ++- src/lxc/start.c | 15 -- 3 files changed, 55 insertions(+), 24 deletions(-) diff --git a/src/lxc/cgroup.c b/src/lxc/cgroup.c ind

Re: [lxc-devel] [PATCH] move monitor-fifo and monitor-sock to /run

Hi Serge, > Thanks, nice cleanup too. One concern though - lxc_monitor_sock_name() > just keeps making a longer and longer path, and it's limited to 108 > bytes. Is there any reason not to use an abstract unix sock for it? > The monitor-fifo doesn't have the length restriction so > $rundir/lxc/$

Re: [lxc-devel] [PATCH] cgroup: re-introduce ns cgroup support

Hi Serge, Sorry about 'ns' support in my rewrite, I completely forgot that it's removal was not so long ago. I have a two very minor nit-picky comments: > +static char *cgroup_rename_nsgroup(char *mountpath, const char *oldname, int > pid, const char *name) > +lxc_cgroup_create(..., int pid) p

Re: [lxc-devel] [PATCH 6/6] cgroup: Major rewrite of cgroup logic

Hi Serge, Thanks for testing / reviewing! > I'd like to just get rid of mountcgroups and make this a > configurable option straight in lxc, which when set will cause lxc, > for every mountpoint which is in handler->cgroup, bind-mount the > the container init's directory into the container. The q

Re: [lxc-devel] [PATCH 3/6] Add fopen_cloexec function to emulate 'e' mode

Hi Serge, > Though the special case for calling open() without a mode arg seems > unnecessary since when called without O_CREAT, mode is supposed to be > ignored. Oh, I never looked too closely at open and I simply went with the function signatures in the manpage. Feel free to simplify that. --

Re: [lxc-devel] [PATCH 4/6] utils: Add string and array utility functions

Hi Serge, > However, a comment about > +/* Normalize and split path: Leading and trailing / are removed, multiple > + * / are compactified, .. and . are resolved (.. on the top level is > considered > + * identical to .). > + * Examples: > + * /-> { NULL } > + * foo/../bar

Re: [lxc-devel] [PATCH 5/6] utils: Add utility functions that write/read to entire files

Hi Serge, > but I notice that lxc_read_line_from_file() is not being used here > or later. The function would seem more useful if it accepted a line > number to read. Otherwise I'd suggest we drop the function. Thoughts? I thought I'd need it at some point so I added it and then I ended up not

Re: [lxc-devel] [RFC] [PATCH 0/6] Major cgroup logic rewrite

Hi Serge, > Thanks, Christian. I did need the trivial white-space-damaged patch below, > but > with that it built and ran for me, both with %n and default (/lxc/%n) > patterns. > This was in a nested container, I haven't tested at host level but have no > reason to think that would fail if nest

[lxc-devel] [PATCH 5/6] utils: Add utility functions that write/read to entire files

Signed-off-by: Christian Seiler --- src/lxc/utils.c | 91 +++ src/lxc/utils.h |5 +++ 2 files changed, 96 insertions(+) diff --git a/src/lxc/utils.c b/src/lxc/utils.c index dc98443..02336d7 100644 --- a/src/lxc/utils.c +++ b/src/lxc

[lxc-devel] [PATCH 4/6] utils: Add string and array utility functions

Adds a few useful string and array manipulation functions to utils.[ch] Signed-off-by: Christian Seiler --- src/lxc/utils.c | 284 +++ src/lxc/utils.h | 32 +++ 2 files changed, 316 insertions(+) diff --git a/src/lxc/utils.c b/src/lxc

[lxc-devel] [PATCH 3/6] Add fopen_cloexec function to emulate 'e' mode

onverts all fopen() calls in utils.c (where the function is added) to fopen_cloexec(). Subsequently, other calls to fopen() and open() should also be adapted. Signed-off-by: Christian Seiler --- src/lxc/utils.c | 50 -- src/lxc/utils.h |3

[lxc-devel] [PATCH 2/6] Add cgroup.pattern global configuration option

Signed-off-by: Christian Seiler --- configure.ac|7 +++ src/lxc/Makefile.am |3 ++- src/lxc/utils.c |1 + 3 files changed, 10 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 4eaf329..f0f417c 100644 --- a/configure.ac +++ b/configure.ac

[lxc-devel] [PATCH 1/6] global config: Unify parsing, add additional checks

Instead of duplicating the code for parsing the global config file for each option, write one main function, lxc_global_config_value, that does the parsing for an arbitrary option name and just call that function from the existing ones. Signed-off-by: Christian Seiler --- src/lxc/utils.c | 137

[lxc-devel] [RFC] [PATCH 0/6] Major cgroup logic rewrite

Hi all, As discussed previously, I've now done a major rewrite of the entire cgroup logic. There are now no assumptions made whatsoever when it comes to the cgroup mount points, the kernel information will be used to determine the proper locations for everything. (Only /proc is assumed to be worki

Re: [lxc-devel] versioning the container monitor api

Hi Serge, > I start a container running a crucial mail server. I upgrade > lxc. The new lxc has changed the format of messages for the > commands api. Now I do 'lxc-list', which queries the running > monitor to check its init pid with LXC_CMD_GET_INIT_PID. The > c

Re: [lxc-devel] [PATCH 1/5] cgroup: minor bugfixes so start and attach work again

Hi Serge, > Ok, how about we make the system-cgroup-dir configurable in > /etc/lxc/lxc.conf? So if you have > > lxc.system-cgroup-dir = /machine > > then root-created containers will end up in /machine (or, if you're > already nested under /lxc/m1, then /lxc/m1/machine). If that is > unset

Re: [lxc-devel] [PATCH 1/5] cgroup: minor bugfixes so start and attach work again

Hi Serge, >> 1. What about the naming convention? Stick with /lxc/$name or go >> with >> /machine/$name.lxc (see prev. email)? Or I could make that >> configurable? > > $name.lxc or lxc.$name seems good for all cases. It'll benefit > unprivileged users also. By "/machine/$name.lxc" did

Re: [lxc-devel] [PATCH 1/5] cgroup: minor bugfixes so start and attach work again

Hi Serge, > If we're going to do this, we should do it soon. Would you have time > in the next few days? Define 'few'. ;) I should be able to do that until Monday (barring any emergencies). > (BTW, if we're going to throw words like b0rked around, I'd prefer to > reserve that for the refusal to

Re: [lxc-devel] LXC and Ubuntu 13.04

Hi Andre, > I've found the following issue running lxc-start on Ubuntu 13.04: > >lxc-start: Read-only file system - failed to change apparmor > profile > to unconfined I had the same issue when playing around and the following patch that is already merged in staging fixes it: https://github

Re: [lxc-devel] [PATCH 1/5] cgroup: minor bugfixes so start and attach work again

Hi Serge, >> Having /lxc makes it much easier to sett what's part of a container >> vs >> what's part of a user session or whatever else uses cgroups these >> days. > > Note that nothing stops you from simply entering cgroup /lxc by hand > before executing a container. Right now the code simply

Re: [lxc-devel] RFC: aliases

Hi Serge, > I'm thinking symbolic link may be the simplest thing to support - > lxc_container_new() could immediately readlink() to get the real > container name. Yes, I agree, I'd find such a thing very useful. However, it should not only be lxc_container_new but also the utilities not using the

Re: [lxc-devel] [PATCH 1/5] cgroup: minor bugfixes so start and attach work again

Hi Serge, >> I do have a very stupid question, however: LXC 0.9 used to set the >> cgroup to /lxc/$name. Now it's just /$name. Is that intentional? > > Hm, it was somewhat unconscious but I didn't really mean to do that. > Some cgroup subsystems do incur a performance penalty for every > extra di

Re: [lxc-devel] [PATCH 1/5] cgroup: minor bugfixes so start and attach work again

Hi Serge, > Thanks, Christian - I've pushed a new patch to github on top of yours. > Regular start/stop/lxc-cgroup stuff is working for me both with all > cgroups composed and separately mounted. I can confirm that it works on my setup. I do have a very stupid question, however: LXC 0.9 used to

Re: [lxc-devel] [PATCH 1/5] cgroup: minor bugfixes so start and attach work again

Hi Serge, > This needs to just be > > oldlen = newlen; Oh, yes, that's right, it's the buffer length and not the string length. Sorry, I did that late at night and some things got mixed up in my head. >> @@ -1128,7 +1152,7 @@ void lxc_cgroup_destroy_desc(struct cgroup_desc >> *cgroups) >

Re: [lxc-devel] lxc-start: Failed to find current cgroup

Hi there, FYI: I had the same problem with current staging and the first patch I sent in my latest series fixes this: http://thread.gmane.org/gmane.linux.kernel.containers.lxc.devel/3977 -- Christian -- Get 100% visibil

[lxc-devel] [PATCH 4/5] python/attach: export CLONE_NEW* constants to Python

Signed-off-by: Christian Seiler --- src/python-lxc/lxc.c | 36 src/python-lxc/lxc/__init__.py |6 ++ 2 files changed, 34 insertions(+), 8 deletions(-) diff --git a/src/python-lxc/lxc.c b/src/python-lxc/lxc.c index f4de169..b2abf38 100644

[lxc-devel] [PATCH 5/5] python/attach: Add function that returns personality for architecture

Adds the arch_to_personality function that looks up an architecture and returns the corresponding personality. This may be used in conjunction with the attach/attach_wait keyword argument. Signed-off-by: Christian Seiler --- src/python-lxc/lxc.c | 32

[lxc-devel] [PATCH 3/5] python/attach: Fix minor memory leaks

Signed-off-by: Christian Seiler --- src/python-lxc/lxc.c | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/src/python-lxc/lxc.c b/src/python-lxc/lxc.c index ddf3fa0..f4de169 100644 --- a/src/python-lxc/lxc.c +++ b/src/python-lxc/lxc.c @@ -759,8 +759,10

[lxc-devel] [PATCH 1/5] cgroup: minor bugfixes so start and attach work again

This fixes some minor bugs in the cgroup logic that made start and attach fail (at least when all cgroup controllers were mounted together). Signed-off-by: Christian Seiler --- src/lxc/cgroup.c | 31 --- src/lxc/commands.c |3 ++- 2 files changed, 30

[lxc-devel] [PATCH 0/5] Bugfixes + minor features w.r.t. attach

Hi, This series can also be found under It consists of 3 parts: * Patch 1 fixes some things that were broken when I tried to work on the attach functionality further. (lxc-start didn't work, lxc-attach didn't work due to some cgroup

[lxc-devel] [PATCH 2/5] attach: Fix minor memory leak in environment variable handling

Signed-off-by: Christian Seiler --- src/lxc/attach.c |6 ++ 1 file changed, 6 insertions(+) diff --git a/src/lxc/attach.c b/src/lxc/attach.c index 950fe9a..2e94b70 100644 --- a/src/lxc/attach.c +++ b/src/lxc/attach.c @@ -292,7 +292,13 @@ int lxc_attach_set_environment(enum

Re: [lxc-devel] [PATCH 8/8] attach: implement remaining options of lxc_attach_set_environment

Hi Serge, >>> The freeing seems unnecessary as you're about to rexit(-1), right? >> >> in the current flow, yes. However, this function may be useful from >> other places where one does not exit if it fails, so I'd rather be a bit >> defensive in the programming style, if possible. > > In that ca

Re: [lxc-devel] [PATCH 8/8] attach: implement remaining options of lxc_attach_set_environment

Hi Serge, >> +if (!extra_keep_store[i]) { >> +SYSERROR("failed to allocate >> memory for storing current " >> + "environment variable >> values that will be kept");

Re: [lxc-devel] [PATCH 2/8] lxc-attach: Completely rework lxc-attach and move to API function

Hi Serge, Thanks for reviewing! >> +/* load apparmor profile */ >> +if ((options->namespaces & CLONE_NEWNS) && (options->attach_flags & >> LXC_ATTACH_APPARMOR)) { >> +ret = attach_apparmor(init_ctx->aa_profile); >> +if (ret < 0) { >> +shutdown(

[lxc-devel] [PATCH 2/8] lxc-attach: Completely rework lxc-attach and move to API function

also be provided. Signed-off-by: Christian Seiler --- src/lxc/attach.c | 495 +- src/lxc/attach.h |8 +- src/lxc/attach_options.h | 120 +++ src/lxc/lxc_attach.c | 407 +++--- src/lx

[lxc-devel] [PATCH 4/8] Add attach support to container C API

Signed-off-by: Christian Seiler --- src/lxc/lxccontainer.c | 124 src/lxc/lxccontainer.h |8 +++- 2 files changed, 80 insertions(+), 52 deletions(-) diff --git a/src/lxc/lxccontainer.c b/src/lxc/lxccontainer.c index 3affe22..1c77b63 100644

[lxc-devel] [PATCH 5/8] apparmor/attach: make sure buffer is NUL-terminated

Signed-off-by: Christian Seiler --- src/lxc/apparmor.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/lxc/apparmor.c b/src/lxc/apparmor.c index a2d6476..cb81464 100644 --- a/src/lxc/apparmor.c +++ b/src/lxc/apparmor.c @@ -42,12 +42,13 @@ again: } sz

[lxc-devel] [PATCH 3/8] Add helper functions to convert va_list of char* to char**.

Signed-off-by: Christian Seiler --- src/lxc/utils.c | 46 ++ src/lxc/utils.h |5 + 2 files changed, 51 insertions(+) diff --git a/src/lxc/utils.c b/src/lxc/utils.c index 89d335d..9dd742b 100644 --- a/src/lxc/utils.c +++ b/src/lxc/utils.c

[lxc-devel] [PATCH 8/8] attach: implement remaining options of lxc_attach_set_environment

This patch implements the extra_env and extra_keep options of lxc_attach_set_environment. The Python implementation, the C container API and the lxc-attach utility are able to utilize this feature; lxc-attach has gained two new command line options for this. Signed-off-by: Christian Seiler

[lxc-devel] [PATCH 7/8] python: add attach support

, since there is no guarantee that the Python installation inside the container is in any way compatible with that outside of it. If you want to run Python code directly, please import all modules before attaching and only use them within the container. Signed-off-by: Christian Seiler --- src/python-lxc

Re: [lxc-devel] Preparation for LXC 1.0 alpha-1

Hi there, If you remember from quite a while ago, I proposed some changes to the attach functionality to make it quite a bit better: http://thread.gmane.org/gmane.linux.kernel.containers.lxc.devel/3429 A few initial patches were already applied back then, some others I wanted to redo with the re

[lxc-devel] [PATCH 0/8] lxc-attach rewrite, attach API

Hi there, This patch set can also be found on my local github tree at: It contains the following main parts: - move attach functionality to attach.c, rewrite it in such a way that the attached process is now a parent of the original p

[lxc-devel] [PATCH 6/8] python: improve convert_tuple_to_char_pointer_array

alloc(...)) Signed-off-by: Christian Seiler --- src/python-lxc/lxc.c | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/src/python-lxc/lxc.c b/src/python-lxc/lxc.c index 18f2224..ec81bbf 100644 --- a/src/python-lxc/lxc.c +++ b/src/python-lxc/lxc.c @@ -34,10 +

[lxc-devel] [PATCH 1/8] Fix return type of read/write utility functions.

Signed-off-by: Christian Seiler --- src/lxc/utils.c | 14 +++--- src/lxc/utils.h |6 +++--- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/src/lxc/utils.c b/src/lxc/utils.c index c3f734b..89d335d 100644 --- a/src/lxc/utils.c +++ b/src/lxc/utils.c @@ -359,9 +359,9

Re: [lxc-devel] [PATCH] fix getline(3) memory leaks

Hi there, > Yeah I've tested before (because I used to want to think glibc would > check for that) and it definately segvs. I'll push this patch with > that added. I'm a bit confused, this goes against everything I know about C memory management: ANSI C (ANSI X3J11/88-090, May 13, 1988) [1], Se

Re: [lxc-devel] [PATCH] [RFC] Complete rewrite of lxc-attach functionality

Hi Serge, >>This is due to user namespaces. The patch introduces a flat > > And pid ns right? Otherwise the task which did setns would look > funky inside the container. iiuc. Yes, of course. > I think d). Create a new attach_struct.h which you #include from both > lxccontainer.h and att

Re: [lxc-devel] [PATCH 5/5] lxc-attach: Completely rework lxc-attach and move to API function

Hi Serge, > Note though when I was talking about putting attach "into the API", > I meant by that adding a lxcapi_attach() function to struct > lxc_container in src/lxc/lxccontainer.{c,h} that python/go/lua can > then call into. That should be trivial to do on top of what you have > here. Were y

[lxc-devel] [PATCH 4/5 v2] Implement simple utility functions for reading and writing to fds

an updated version of this specific patch with the fixed return values. (The other patches should still apply regardless.) -- Christian >From 20c3cc93835e6148a61686cd32ceb09f39eb1bfc Mon Sep 17 00:00:00 2001 From: Christian Seiler Date: Wed, 8 May 2013 14:37:15 +0200 Subject: [PATCH 4/5 v2] I

Re: [lxc-devel] [PATCH 1/3] lxc-stop: use api, remove lxc_shutdown, extend lxc-stop functionality

Hi, > [ Christian: this should be a good starting point for adding the > lxc.signal.{halt,reboot,kill}, etc. If you don't have time, I'll > get back to looking at that later. Thanks! ] Will do that in the next few days. > Also if the container is not running, return -2. Currently > lxc-stop w

Re: [lxc-devel] [PATCH] [RFC] Complete rewrite of lxc-attach functionality

Hi again, Oh, I forgot, I've also added the patches to my github tree, you can find them in the branch: https://github.com/chris-se/lxc/tree/attach-rewrite -- Christian -- AlienVault Unified Security Management (USM) pl

[lxc-devel] [PATCH 5/5] lxc-attach: Completely rework lxc-attach and move to API function

- Move attach functionality to a completely new API function for attaching to containers. The API functions accepts the name of the container, the lxcpath, a structure indicating options for attaching and returns the pid of the attached process. The calling thread may then use waitpid(

[lxc-devel] [PATCH 2/5] utils.c: Add lxc_wait_for_pid_status routine that returns exit code

Signed-off-by: Christian Seiler --- src/lxc/utils.c | 16 src/lxc/utils.h |3 +++ 2 files changed, 19 insertions(+), 0 deletions(-) diff --git a/src/lxc/utils.c b/src/lxc/utils.c index cf42c38..66bd19d 100644 --- a/src/lxc/utils.c +++ b/src/lxc/utils.c @@ -265,3 +265,19

[lxc-devel] [PATCH] [RFC] Complete rewrite of lxc-attach functionality

Hi, as discussed previously on this list, I've reimplemented the lxc-attach functionality as an API function. The patchset consists of two parts: 1. Four minor patches that just fix some bugs, shuffle definitions around and implement some small utility functions that I need for the attac

[lxc-devel] [PATCH 4/5] Implement simple utility functions for reading and writing to fds

Signed-off-by: Christian Seiler --- src/lxc/utils.c | 35 +++ src/lxc/utils.h |5 + 2 files changed, 40 insertions(+), 0 deletions(-) diff --git a/src/lxc/utils.c b/src/lxc/utils.c index 66bd19d..cd35e00 100644 --- a/src/lxc/utils.c +++ b/src/lxc

[lxc-devel] [PATCH 1/5] wait_for_pid: Fix EINTR check

Signed-off-by: Christian Seiler --- src/lxc/utils.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/lxc/utils.c b/src/lxc/utils.c index be1ce88..cf42c38 100644 --- a/src/lxc/utils.c +++ b/src/lxc/utils.c @@ -255,7 +255,7 @@ int wait_for_pid(pid_t pid) again

[lxc-devel] [PATCH 3/5] Move declarations of some constants to where they are needed.

Signed-off-by: Christian Seiler --- src/lxc/bdev.h | 26 ++ src/lxc/conf.c | 24 2 files changed, 26 insertions(+), 24 deletions(-) diff --git a/src/lxc/bdev.h b/src/lxc/bdev.h index cc03592..d69efd8 100644 --- a/src/lxc/bdev.h +++ b/src/lxc

Re: [lxc-devel] [PATCH 1/3] lxc-shutdown: switch from script to program using api.

Hello Serge, > Ok, I've got no objection to this, but if I decide to do this before > resending the patch I won't get around to it for quite some time. I'll > push a github tree with a simpler consolidated patch, and if you have > time to implement the above in a branch based on what I push, plea

Re: [lxc-devel] [PATCH 1/3] lxc-shutdown: switch from script to program using api.

Hi there, > So my suggestion is basically to: > - Kill lxc-shutdown > - Change lxc-stop so that: >* Default behaviour is to call shutdown(), wait 15s for STOPPED, if > not STOPPED, print a message to the user and call stop() >* We have a -r option to reboot the container (with proper che

Re: [lxc-devel] [PATCH] lxc-ps: handle cgroup collisions

Hi Serge, a quick comment: > +if lxc-info -P $lxc_path -t RUNNING -n z1; then Just from reading the patch without testing it: s/z1/$container/ -- Christian -- Learn Graph Databases - Download FREE O'Reilly Book "G

Re: [lxc-devel] RFC: Refactoring lxc-attach

Hi there, any comments on my proposal? > The basic idea for the refactored attach API would be: > > - pid_t lxc_attach(const char* name, const char* lxcpath, > options...) > + create a socket pair for sync > + fork() (get rid of threading, nss stuff, etc.) > |- same pro

[lxc-devel] RFC: Refactoring lxc-attach

Hi there, Just a comment on my patch: > This patch just changes the code in the most simple manner to use > clone() instead of fork(). Since clone() requires a function to be > called instead of returning 0, we move the code of the child into a > function child_main. I wanted to make the patch a

[lxc-devel] [PATCH 1/1] lxc_attach: Use clone() instead of second fork()

ioned assertion. This patch just changes the code in the most simple manner to use clone() instead of fork(). Since clone() requires a function to be called instead of returning 0, we move the code of the child into a function child_main. Signed-off-by: Christian Seiler --- src/lxc/lxc_att

Re: [lxc-devel] setns/fork(glibc) weird interaction, lxc-attach may hang sporadically

Hi again, > util-linux is affected the same way as far as I can tell (haven't > tried > it though), and should run into the assertion and fail for no good > reason. Btw. I just noticed: -F is actually worse than not using -F. If you use the -F flag for nsenter, nsenter itself will not fork(), bu

Re: [lxc-devel] setns/fork(glibc) weird interaction, lxc-attach may hang sporadically

Hi, > Hi Christian, I agree we need a short term solution and one that > works > with existing glibcs. My question is if you think that glibc will > eventually fix this at some point? Actually, I was just compiling a bug report for glibc and I had another look at the stack trace - it appears to

Re: [lxc-devel] setns/fork(glibc) weird interaction, lxc-attach may hang sporadically

Hi there, >> - Call the fork syscall directly via syscall(__NR_fork) >> Since lxc-attach is single-threaded anyway, the things glibc >> does > > lxc-attach isn't but at some point we'll want attach in the API, and > that is not single-threaded. Now that I think about it, we do fork() in th

[lxc-devel] setns/fork(glibc) weird interaction, lxc-attach may hang sporadically

Hi there, I've found a problem that comes from the interaction between setns() and glibc's implementation of fork() (at least on x86_64). It is rather complicated to describe, and forgive me if my mail is very long. I know of several ways how to address the problem but wanted to have a discussion

Re: [lxc-devel] [PATCH] Use container specific domain socket name

Hi there, > Let's say I do > > sudo lxc-monitor -n r1 -n r2 > > and now do > > sudo lxc-start -n r1 > > How do we know to send the 'started' event to the lxc-monitor, since > there was not yet a lxc-start daemon running? Just to throw my 2¢ in there - why not use DBus for that? It

Re: [lxc-devel] LXC 0.9 release, staging branch re-opened for 1.0

Hi there, > A draft roadmap for 1.0 can be found at: > https://wiki.ubuntu.com/LXC/1.0-roadmap > > Feel free to add items to that list. We'll use the mailing-list to > coordinate the work as usual. I've been working on using LXC containers in a Pacemaker (Linux-HA) environment, i.e. writing reso

  1   2   3   >