[lxc-devel] about LXC's coding style
Hi Serge and Stéphane and list, I'm sorry but I need to complain about this :( I saw LXC's CONTRIBUTING file, it says: "The coding style follows the Linux kernel coding style" But after reading code these days, there are too many very-long-line codes, especially in cgroup.c, this really cause some inconvenience, when reading LXC code, I can't vsplit my vim any more :( I don't know if this is an issue for other guys, can we keep the rules for the future reviews? Thanks and best regards. Qiang ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [PATCH 1/2] lxc-start: fix the container leak when daemonize
When start container with daemon model, we'll have a new daemon
process in lxcapi_start, whose c->numthreads is 2, inherited
from his father. Even his father return to main(), the
lxc_container_put won't affect son's numthreads.
So when daemon stops, he should return to main and do
lxc_container_put again, rather than exit and leave the
container alone.
Signed-off-by: Qiang Huang
---
src/lxc/lxccontainer.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/src/lxc/lxccontainer.c b/src/lxc/lxccontainer.c
index 0bebdff..ddea0d7 100644
--- a/src/lxc/lxccontainer.c
+++ b/src/lxc/lxccontainer.c
@@ -632,12 +632,10 @@ reboot:
goto reboot;
}
- if (daemonize) {
+ if (daemonize)
lxc_container_put(c);
- exit (ret == 0 ? true : false);
- } else {
- return (ret == 0 ? true : false);
- }
+
+ return (ret == 0 ? true : false);
}
/*
--
1.8.3
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [PATCH 2/2] daemon: remove pidfile when daemon container is stopped
This is for bug: https://github.com/lxc/lxc/issues/89
When start container with daemon model, the daemon process's
father will return back to main in start time, and pidfile
is removed then, that's not right.
So we store pidfile to lxc_container, and remove it when
lxc_container_free.
Signed-off-by: Qiang Huang
---
src/lxc/lxc_start.c| 9 +
src/lxc/lxccontainer.c | 6 ++
src/lxc/lxccontainer.h | 6 ++
3 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/src/lxc/lxc_start.c b/src/lxc/lxc_start.c
index d5379da..fd2dc6e 100644
--- a/src/lxc/lxc_start.c
+++ b/src/lxc/lxc_start.c
@@ -302,6 +302,11 @@ int main(int argc, char *argv[])
}
if (my_args.pidfile != NULL) {
+ if (ensure_path(&c->pidfile, my_args.pidfile) < 0) {
+ ERROR("failed to ensure pidfile '%s'", my_args.pidfile);
+ goto out;
+ }
+
pid_fp = fopen(my_args.pidfile, "w");
if (pid_fp == NULL) {
SYSERROR("failed to create pidfile '%s' for '%s'",
@@ -342,10 +347,6 @@ int main(int argc, char *argv[])
c->want_close_all_fds(c, true);
err = c->start(c, 0, args) ? 0 : -1;
-
- if (my_args.pidfile)
- unlink(my_args.pidfile);
-
out:
lxc_container_put(c);
if (pid_fp)
diff --git a/src/lxc/lxccontainer.c b/src/lxc/lxccontainer.c
index ddea0d7..d742781 100644
--- a/src/lxc/lxccontainer.c
+++ b/src/lxc/lxccontainer.c
@@ -231,6 +231,11 @@ static void lxc_container_free(struct lxc_container *c)
free(c->config_path);
c->config_path = NULL;
}
+ if (c->pidfile) {
+ unlink(c->pidfile);
+ free(c->pidfile);
+ c->pidfile = NULL;
+ }
free(c);
}
@@ -3051,6 +3056,7 @@ struct lxc_container *lxc_container_new(const char *name,
const char *configpath
lxcapi_clear_config(c);
}
c->daemonize = true;
+ c->pidfile = NULL;
// assign the member functions
c->is_defined = lxcapi_is_defined;
diff --git a/src/lxc/lxccontainer.h b/src/lxc/lxccontainer.h
index 921e47d..a860648 100644
--- a/src/lxc/lxccontainer.h
+++ b/src/lxc/lxccontainer.h
@@ -68,6 +68,12 @@ struct lxc_container {
/*!
* \private
+* File to store pid.
+*/
+ char *pidfile;
+
+ /*!
+* \private
* Container semaphore lock.
*/
struct lxc_lock *slock;
--
1.8.3
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] templates and "common.conf"
Hi, I was starting conversion to common.conf style for gentoo template. I understand why ubuntu which has more than one template need factoring. I don't understand the point to do it for other "mono-template" distro : "I share common settings with myself" :-) Why don't we make one real common.conf shared over all distros ? Should I propose it ? Guillaume ZITTA ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] handle unprivileged user calls more gracefully (v2)
On Sat, Jan 18, 2014 at 12:12 AM, Stéphane Graber wrote: > On Sat, Jan 18, 2014 at 12:03:19AM -0500, S.Çağlar Onur wrote: >> On Sat, Jan 18, 2014 at 12:00 AM, Stéphane Graber >> wrote: >> > On Fri, Jan 17, 2014 at 11:58:17PM -0500, S.Çağlar Onur wrote: >> >> On Fri, Jan 17, 2014 at 11:49 PM, Stéphane Graber >> >> wrote: >> >> > On Fri, Jan 17, 2014 at 11:34:50PM -0500, S.Çağlar Onur wrote: >> >> >> Return an error if the function is not supposed to be called by an >> >> >> unprivileged user. >> >> >> Otherwise those calls fail in the middle of their execution with >> >> >> different reasons. >> >> >> >> >> >> changes since v1: >> >> >> - am_unpriv is now a simple geteuid check, >> >> >> - API functions are now providing error messages, >> >> >> - lxc-info, lxc-attach and lxc-execute are now checking geteuid >> >> >> >> >> > >> >> > That looks much better to me, though I disagree that lxc-execute doesn't >> >> > work. It certainly is a bit restricted compared ot its system >> >> > equivalent, but all of those limitations will be the same as with >> >> > lxc-start. >> >> > >> >> > stgraber@castiana:~$ lxc-execute -n p1 -- /bin/bash >> >> > lxc-init: failed to mount /proc : Device or resource busy >> >> > lxc-init: failed to mount /dev/shm : No such file or directory >> >> > root@p1:/# >> >> >> >> Hmm then I must be having some kind of trouble here with it. I can >> >> start/stop containers just fine >> >> >> >> [caglar@oOo:~/go/src/github.com/caglar10ur/lxc/examples] lxc-start -d -n >> >> rubik >> >> [caglar@oOo:~/go/src/github.com/caglar10ur/lxc/examples] lxc-ls --fancy >> >> NAME STATEIPV4 IPV6 AUTOSTART >> >> --- >> >> rubik RUNNING UNKNOWN UNKNOWN NO >> >> [caglar@oOo:~/go/src/github.com/caglar10ur/lxc/examples] lxc-stop -n rubik >> >> >> >> sudo variant works just fine >> >> >> >> [caglar@oOo:~/go/src/github.com/caglar10ur/lxc/examples] sudo >> >> lxc-execute -n p1 -- /bin/bash >> >> root@oOo:/home/caglar/go/src/github.com/caglar10ur/lxc/examples# exit >> >> [caglar@oOo:~/go/src/github.com/caglar10ur/lxc/examples] >> >> >> >> but plain one gives this >> >> >> >> [caglar@oOo:~/go/src/github.com/caglar10ur/lxc/examples] lxc-execute >> >> -n p1 -- /bin/bash >> >> lxc-execute: Operation not permitted - failed to clone >> >> >> >> lxc-execute: failed to clone(0x6c02): Operation not permitted >> >> lxc-execute: Operation not permitted - failed to fork into a new namespace >> >> lxc-execute: failed to spawn 'p1' >> > >> > Try rubik instead of p1. >> >> [caglar@oOo:~/Projects/lxc(master)] lxc-execute -n rubik -- /bin/bash >> lxc-execute: No such file or directory - failed to mount >> '/sys/firmware/efi/efivars' on >> '/usr/lib/x86_64-linux-gnu/lxc/rootfs/sys/firmware/efi/efivars' > That's because you aren't on an EFI system. Yep and commenting out that line from /usr/share/lxc/config/ubuntu.userns.conf solves that > >> lxc-execute: Failed to find an lxc-init >> lxc-execute: invalid sequence number 1. expected 4 >> lxc-execute: failed to spawn 'rubik' > > That's because you don't have lxc-init installed in the container's rootfs. Ahh, actually I have but apparently my host system uses "/usr/libexec/lxc/lxc-init" but installing lxc package inside the container puts the lxc-init into "/usr/lib/x86_64-linux-gnu/lxc/lxc-init". Adding some debug code helped to find that [caglar@oOo:~/Projects/lxc(master)] lxc-execute -n rubik -- ls lxc-execute: LOOKING /usr/libexec/lxc/lxc-init lxc-execute: LOOKING /usr/lib/lxc/lxc-init lxc-execute: LOOKING /sbin/lxc-init lxc-execute: Failed to find an lxc-init >> lxc-execute: Device or resource busy - cgroup_rmdir: failed to delete >> /sys/fs/cgroup/hugetlb/caglar/rubik-3 >> lxc-execute: Device or resource busy - cgroup_rmdir: failed to delete >> /sys/fs/cgroup/perf_event/caglar/rubik-3 >> lxc-execute: Device or resource busy - cgroup_rmdir: failed to delete >> /sys/fs/cgroup/blkio/caglar/rubik-3 >> lxc-execute: Device or resource busy - cgroup_rmdir: failed to delete >> /sys/fs/cgroup/freezer/caglar/rubik-3 >> lxc-execute: Device or resource busy - cgroup_rmdir: failed to delete >> /sys/fs/cgroup/devices/caglar/rubik-3 >> lxc-execute: Device or resource busy - cgroup_rmdir: failed to delete >> /sys/fs/cgroup/memory/caglar/rubik-3 >> lxc-execute: Device or resource busy - cgroup_rmdir: failed to delete >> /sys/fs/cgroup/cpuacct/caglar/rubik-3 >> lxc-execute: Device or resource busy - cgroup_rmdir: failed to delete >> /sys/fs/cgroup/cpu/caglar/rubik-3 >> lxc-execute: Device or resource busy - cgroup_rmdir: failed to delete >> /sys/fs/cgroup/cpuset/caglar/rubik-3 > > That's because the container is already running. Nope, guessing those are just artifact of not being able to find lxc-init. [caglar@oOo:~/Projects/lxc(master)] lxc-ls --fancy NAME STATEIPV4 IPV6 AUTOSTART - rubik STOPPED - - NO [caglar@oOo:~/Projects/lxc(master)] lxc-execute -n rubik -- /bin/
Re: [lxc-devel] [PATCH] handle unprivileged user calls more gracefully (v2)
On Sat, Jan 18, 2014 at 12:03:19AM -0500, S.Çağlar Onur wrote: > On Sat, Jan 18, 2014 at 12:00 AM, Stéphane Graber wrote: > > On Fri, Jan 17, 2014 at 11:58:17PM -0500, S.Çağlar Onur wrote: > >> On Fri, Jan 17, 2014 at 11:49 PM, Stéphane Graber > >> wrote: > >> > On Fri, Jan 17, 2014 at 11:34:50PM -0500, S.Çağlar Onur wrote: > >> >> Return an error if the function is not supposed to be called by an > >> >> unprivileged user. > >> >> Otherwise those calls fail in the middle of their execution with > >> >> different reasons. > >> >> > >> >> changes since v1: > >> >> - am_unpriv is now a simple geteuid check, > >> >> - API functions are now providing error messages, > >> >> - lxc-info, lxc-attach and lxc-execute are now checking geteuid > >> >> > >> > > >> > That looks much better to me, though I disagree that lxc-execute doesn't > >> > work. It certainly is a bit restricted compared ot its system > >> > equivalent, but all of those limitations will be the same as with > >> > lxc-start. > >> > > >> > stgraber@castiana:~$ lxc-execute -n p1 -- /bin/bash > >> > lxc-init: failed to mount /proc : Device or resource busy > >> > lxc-init: failed to mount /dev/shm : No such file or directory > >> > root@p1:/# > >> > >> Hmm then I must be having some kind of trouble here with it. I can > >> start/stop containers just fine > >> > >> [caglar@oOo:~/go/src/github.com/caglar10ur/lxc/examples] lxc-start -d -n > >> rubik > >> [caglar@oOo:~/go/src/github.com/caglar10ur/lxc/examples] lxc-ls --fancy > >> NAME STATEIPV4 IPV6 AUTOSTART > >> --- > >> rubik RUNNING UNKNOWN UNKNOWN NO > >> [caglar@oOo:~/go/src/github.com/caglar10ur/lxc/examples] lxc-stop -n rubik > >> > >> sudo variant works just fine > >> > >> [caglar@oOo:~/go/src/github.com/caglar10ur/lxc/examples] sudo > >> lxc-execute -n p1 -- /bin/bash > >> root@oOo:/home/caglar/go/src/github.com/caglar10ur/lxc/examples# exit > >> [caglar@oOo:~/go/src/github.com/caglar10ur/lxc/examples] > >> > >> but plain one gives this > >> > >> [caglar@oOo:~/go/src/github.com/caglar10ur/lxc/examples] lxc-execute > >> -n p1 -- /bin/bash > >> lxc-execute: Operation not permitted - failed to clone > >> > >> lxc-execute: failed to clone(0x6c02): Operation not permitted > >> lxc-execute: Operation not permitted - failed to fork into a new namespace > >> lxc-execute: failed to spawn 'p1' > > > > Try rubik instead of p1. > > [caglar@oOo:~/Projects/lxc(master)] lxc-execute -n rubik -- /bin/bash > lxc-execute: No such file or directory - failed to mount > '/sys/firmware/efi/efivars' on > '/usr/lib/x86_64-linux-gnu/lxc/rootfs/sys/firmware/efi/efivars' That's because you aren't on an EFI system. > lxc-execute: Failed to find an lxc-init > lxc-execute: invalid sequence number 1. expected 4 > lxc-execute: failed to spawn 'rubik' That's because you don't have lxc-init installed in the container's rootfs. > lxc-execute: Device or resource busy - cgroup_rmdir: failed to delete > /sys/fs/cgroup/hugetlb/caglar/rubik-3 > lxc-execute: Device or resource busy - cgroup_rmdir: failed to delete > /sys/fs/cgroup/perf_event/caglar/rubik-3 > lxc-execute: Device or resource busy - cgroup_rmdir: failed to delete > /sys/fs/cgroup/blkio/caglar/rubik-3 > lxc-execute: Device or resource busy - cgroup_rmdir: failed to delete > /sys/fs/cgroup/freezer/caglar/rubik-3 > lxc-execute: Device or resource busy - cgroup_rmdir: failed to delete > /sys/fs/cgroup/devices/caglar/rubik-3 > lxc-execute: Device or resource busy - cgroup_rmdir: failed to delete > /sys/fs/cgroup/memory/caglar/rubik-3 > lxc-execute: Device or resource busy - cgroup_rmdir: failed to delete > /sys/fs/cgroup/cpuacct/caglar/rubik-3 > lxc-execute: Device or resource busy - cgroup_rmdir: failed to delete > /sys/fs/cgroup/cpu/caglar/rubik-3 > lxc-execute: Device or resource busy - cgroup_rmdir: failed to delete > /sys/fs/cgroup/cpuset/caglar/rubik-3 That's because the container is already running. > > I realized that I'm using cgmanager on this box, maybe I'm observing > this because of it? > > >> > >> > >> > It may be worth teaching lxc_init a bit about unprivileged containers > >> > but besides that, if all I wanted to do was run a command using that > >> > container rootfs, it'd work. > >> > > >> > The rest I think looks good and hopefully we can drop quite a few of > >> > those before the 1.0 release. It shouldn't be too hard to get basic dir > >> > cloning working and a good chunk of the rest would get resolved if we > >> > had attach working. > >> > > >> > Ideally, we'd release with only the snapshot functions and the > >> > add/remove device function disabled as those simply aren't doable at > >> > this point. > >> > > >> >> Signed-off-by: S.Çağlar Onur > >> >> --- > >> >> src/lxc/lxc_attach.c | 5 > >> >> src/lxc/lxc_execute.c | 5 > >> >> src/lxc/lxc_info.c | 20 +++-- > >> >> src/lxc/lxccontainer.c | 78 > >> >> ++
Re: [lxc-devel] [PATCH] handle unprivileged user calls more gracefully (v2)
On Sat, Jan 18, 2014 at 12:00 AM, Stéphane Graber wrote: > On Fri, Jan 17, 2014 at 11:58:17PM -0500, S.Çağlar Onur wrote: >> On Fri, Jan 17, 2014 at 11:49 PM, Stéphane Graber >> wrote: >> > On Fri, Jan 17, 2014 at 11:34:50PM -0500, S.Çağlar Onur wrote: >> >> Return an error if the function is not supposed to be called by an >> >> unprivileged user. >> >> Otherwise those calls fail in the middle of their execution with >> >> different reasons. >> >> >> >> changes since v1: >> >> - am_unpriv is now a simple geteuid check, >> >> - API functions are now providing error messages, >> >> - lxc-info, lxc-attach and lxc-execute are now checking geteuid >> >> >> > >> > That looks much better to me, though I disagree that lxc-execute doesn't >> > work. It certainly is a bit restricted compared ot its system >> > equivalent, but all of those limitations will be the same as with >> > lxc-start. >> > >> > stgraber@castiana:~$ lxc-execute -n p1 -- /bin/bash >> > lxc-init: failed to mount /proc : Device or resource busy >> > lxc-init: failed to mount /dev/shm : No such file or directory >> > root@p1:/# >> >> Hmm then I must be having some kind of trouble here with it. I can >> start/stop containers just fine >> >> [caglar@oOo:~/go/src/github.com/caglar10ur/lxc/examples] lxc-start -d -n >> rubik >> [caglar@oOo:~/go/src/github.com/caglar10ur/lxc/examples] lxc-ls --fancy >> NAME STATEIPV4 IPV6 AUTOSTART >> --- >> rubik RUNNING UNKNOWN UNKNOWN NO >> [caglar@oOo:~/go/src/github.com/caglar10ur/lxc/examples] lxc-stop -n rubik >> >> sudo variant works just fine >> >> [caglar@oOo:~/go/src/github.com/caglar10ur/lxc/examples] sudo >> lxc-execute -n p1 -- /bin/bash >> root@oOo:/home/caglar/go/src/github.com/caglar10ur/lxc/examples# exit >> [caglar@oOo:~/go/src/github.com/caglar10ur/lxc/examples] >> >> but plain one gives this >> >> [caglar@oOo:~/go/src/github.com/caglar10ur/lxc/examples] lxc-execute >> -n p1 -- /bin/bash >> lxc-execute: Operation not permitted - failed to clone >> >> lxc-execute: failed to clone(0x6c02): Operation not permitted >> lxc-execute: Operation not permitted - failed to fork into a new namespace >> lxc-execute: failed to spawn 'p1' > > Try rubik instead of p1. [caglar@oOo:~/Projects/lxc(master)] lxc-execute -n rubik -- /bin/bash lxc-execute: No such file or directory - failed to mount '/sys/firmware/efi/efivars' on '/usr/lib/x86_64-linux-gnu/lxc/rootfs/sys/firmware/efi/efivars' lxc-execute: Failed to find an lxc-init lxc-execute: invalid sequence number 1. expected 4 lxc-execute: failed to spawn 'rubik' lxc-execute: Device or resource busy - cgroup_rmdir: failed to delete /sys/fs/cgroup/hugetlb/caglar/rubik-3 lxc-execute: Device or resource busy - cgroup_rmdir: failed to delete /sys/fs/cgroup/perf_event/caglar/rubik-3 lxc-execute: Device or resource busy - cgroup_rmdir: failed to delete /sys/fs/cgroup/blkio/caglar/rubik-3 lxc-execute: Device or resource busy - cgroup_rmdir: failed to delete /sys/fs/cgroup/freezer/caglar/rubik-3 lxc-execute: Device or resource busy - cgroup_rmdir: failed to delete /sys/fs/cgroup/devices/caglar/rubik-3 lxc-execute: Device or resource busy - cgroup_rmdir: failed to delete /sys/fs/cgroup/memory/caglar/rubik-3 lxc-execute: Device or resource busy - cgroup_rmdir: failed to delete /sys/fs/cgroup/cpuacct/caglar/rubik-3 lxc-execute: Device or resource busy - cgroup_rmdir: failed to delete /sys/fs/cgroup/cpu/caglar/rubik-3 lxc-execute: Device or resource busy - cgroup_rmdir: failed to delete /sys/fs/cgroup/cpuset/caglar/rubik-3 I realized that I'm using cgmanager on this box, maybe I'm observing this because of it? >> >> >> > It may be worth teaching lxc_init a bit about unprivileged containers >> > but besides that, if all I wanted to do was run a command using that >> > container rootfs, it'd work. >> > >> > The rest I think looks good and hopefully we can drop quite a few of >> > those before the 1.0 release. It shouldn't be too hard to get basic dir >> > cloning working and a good chunk of the rest would get resolved if we >> > had attach working. >> > >> > Ideally, we'd release with only the snapshot functions and the >> > add/remove device function disabled as those simply aren't doable at >> > this point. >> > >> >> Signed-off-by: S.Çağlar Onur >> >> --- >> >> src/lxc/lxc_attach.c | 5 >> >> src/lxc/lxc_execute.c | 5 >> >> src/lxc/lxc_info.c | 20 +++-- >> >> src/lxc/lxccontainer.c | 78 >> >> ++ >> >> 4 files changed, 95 insertions(+), 13 deletions(-) >> >> >> >> diff --git a/src/lxc/lxc_attach.c b/src/lxc/lxc_attach.c >> >> index 6744c05..1159d09 100644 >> >> --- a/src/lxc/lxc_attach.c >> >> +++ b/src/lxc/lxc_attach.c >> >> @@ -188,6 +188,11 @@ int main(int argc, char *argv[]) >> >> lxc_attach_options_t attach_options = LXC_ATTACH_OPTIONS_DEFAULT; >> >> lxc_attach_command_t command; >> >> >> >> +if (geteuid()
Re: [lxc-devel] [PATCH] handle unprivileged user calls more gracefully (v2)
On Fri, Jan 17, 2014 at 11:58:17PM -0500, S.Çağlar Onur wrote:
> On Fri, Jan 17, 2014 at 11:49 PM, Stéphane Graber wrote:
> > On Fri, Jan 17, 2014 at 11:34:50PM -0500, S.Çağlar Onur wrote:
> >> Return an error if the function is not supposed to be called by an
> >> unprivileged user.
> >> Otherwise those calls fail in the middle of their execution with different
> >> reasons.
> >>
> >> changes since v1:
> >> - am_unpriv is now a simple geteuid check,
> >> - API functions are now providing error messages,
> >> - lxc-info, lxc-attach and lxc-execute are now checking geteuid
> >>
> >
> > That looks much better to me, though I disagree that lxc-execute doesn't
> > work. It certainly is a bit restricted compared ot its system
> > equivalent, but all of those limitations will be the same as with
> > lxc-start.
> >
> > stgraber@castiana:~$ lxc-execute -n p1 -- /bin/bash
> > lxc-init: failed to mount /proc : Device or resource busy
> > lxc-init: failed to mount /dev/shm : No such file or directory
> > root@p1:/#
>
> Hmm then I must be having some kind of trouble here with it. I can
> start/stop containers just fine
>
> [caglar@oOo:~/go/src/github.com/caglar10ur/lxc/examples] lxc-start -d -n rubik
> [caglar@oOo:~/go/src/github.com/caglar10ur/lxc/examples] lxc-ls --fancy
> NAME STATEIPV4 IPV6 AUTOSTART
> ---
> rubik RUNNING UNKNOWN UNKNOWN NO
> [caglar@oOo:~/go/src/github.com/caglar10ur/lxc/examples] lxc-stop -n rubik
>
> sudo variant works just fine
>
> [caglar@oOo:~/go/src/github.com/caglar10ur/lxc/examples] sudo
> lxc-execute -n p1 -- /bin/bash
> root@oOo:/home/caglar/go/src/github.com/caglar10ur/lxc/examples# exit
> [caglar@oOo:~/go/src/github.com/caglar10ur/lxc/examples]
>
> but plain one gives this
>
> [caglar@oOo:~/go/src/github.com/caglar10ur/lxc/examples] lxc-execute
> -n p1 -- /bin/bash
> lxc-execute: Operation not permitted - failed to clone
>
> lxc-execute: failed to clone(0x6c02): Operation not permitted
> lxc-execute: Operation not permitted - failed to fork into a new namespace
> lxc-execute: failed to spawn 'p1'
Try rubik instead of p1.
>
>
> > It may be worth teaching lxc_init a bit about unprivileged containers
> > but besides that, if all I wanted to do was run a command using that
> > container rootfs, it'd work.
> >
> > The rest I think looks good and hopefully we can drop quite a few of
> > those before the 1.0 release. It shouldn't be too hard to get basic dir
> > cloning working and a good chunk of the rest would get resolved if we
> > had attach working.
> >
> > Ideally, we'd release with only the snapshot functions and the
> > add/remove device function disabled as those simply aren't doable at
> > this point.
> >
> >> Signed-off-by: S.Çağlar Onur
> >> ---
> >> src/lxc/lxc_attach.c | 5
> >> src/lxc/lxc_execute.c | 5
> >> src/lxc/lxc_info.c | 20 +++--
> >> src/lxc/lxccontainer.c | 78
> >> ++
> >> 4 files changed, 95 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/src/lxc/lxc_attach.c b/src/lxc/lxc_attach.c
> >> index 6744c05..1159d09 100644
> >> --- a/src/lxc/lxc_attach.c
> >> +++ b/src/lxc/lxc_attach.c
> >> @@ -188,6 +188,11 @@ int main(int argc, char *argv[])
> >> lxc_attach_options_t attach_options = LXC_ATTACH_OPTIONS_DEFAULT;
> >> lxc_attach_command_t command;
> >>
> >> +if (geteuid() != 0) {
> >> +ERROR("lxc-attach is not currently supported with
> >> unprivileged containers");
> >> +return -1;
> >> +}
> >> +
> >> ret = lxc_caps_init();
> >> if (ret)
> >> return ret;
> >> diff --git a/src/lxc/lxc_execute.c b/src/lxc/lxc_execute.c
> >> index 6a54bf6..8177ed3 100644
> >> --- a/src/lxc/lxc_execute.c
> >> +++ b/src/lxc/lxc_execute.c
> >> @@ -92,6 +92,11 @@ int main(int argc, char *argv[])
> >> char *rcfile;
> >> struct lxc_conf *conf;
> >>
> >> +if (geteuid() != 0) {
> >> +ERROR("lxc-execute is not currently supported with
> >> unprivileged containers");
> >> +return -1;
> >> +}
> >> +
> >> lxc_list_init(&defines);
> >>
> >> if (lxc_caps_init())
> >> diff --git a/src/lxc/lxc_info.c b/src/lxc/lxc_info.c
> >> index b515087..0990036 100644
> >> --- a/src/lxc/lxc_info.c
> >> +++ b/src/lxc/lxc_info.c
> >> @@ -310,15 +310,19 @@ static int print_info(const char *name, const char
> >> *lxcpath)
> >> }
> >>
> >> if (ips) {
> >> - char **addresses = c->get_ips(c, NULL, NULL, 0);
> >> - if (addresses) {
> >> - char *address;
> >> - i = 0;
> >> - while (addresses[i]) {
> >> - address = addresses[i];
> >> - print_info_msg_str("IP:", address);
> >> - i++;
> >> + if (geteuid() == 0) {
> >> +
Re: [lxc-devel] [PATCH] handle unprivileged user calls more gracefully (v2)
On Fri, Jan 17, 2014 at 11:49 PM, Stéphane Graber wrote:
> On Fri, Jan 17, 2014 at 11:34:50PM -0500, S.Çağlar Onur wrote:
>> Return an error if the function is not supposed to be called by an
>> unprivileged user.
>> Otherwise those calls fail in the middle of their execution with different
>> reasons.
>>
>> changes since v1:
>> - am_unpriv is now a simple geteuid check,
>> - API functions are now providing error messages,
>> - lxc-info, lxc-attach and lxc-execute are now checking geteuid
>>
>
> That looks much better to me, though I disagree that lxc-execute doesn't
> work. It certainly is a bit restricted compared ot its system
> equivalent, but all of those limitations will be the same as with
> lxc-start.
>
> stgraber@castiana:~$ lxc-execute -n p1 -- /bin/bash
> lxc-init: failed to mount /proc : Device or resource busy
> lxc-init: failed to mount /dev/shm : No such file or directory
> root@p1:/#
Hmm then I must be having some kind of trouble here with it. I can
start/stop containers just fine
[caglar@oOo:~/go/src/github.com/caglar10ur/lxc/examples] lxc-start -d -n rubik
[caglar@oOo:~/go/src/github.com/caglar10ur/lxc/examples] lxc-ls --fancy
NAME STATEIPV4 IPV6 AUTOSTART
---
rubik RUNNING UNKNOWN UNKNOWN NO
[caglar@oOo:~/go/src/github.com/caglar10ur/lxc/examples] lxc-stop -n rubik
sudo variant works just fine
[caglar@oOo:~/go/src/github.com/caglar10ur/lxc/examples] sudo
lxc-execute -n p1 -- /bin/bash
root@oOo:/home/caglar/go/src/github.com/caglar10ur/lxc/examples# exit
[caglar@oOo:~/go/src/github.com/caglar10ur/lxc/examples]
but plain one gives this
[caglar@oOo:~/go/src/github.com/caglar10ur/lxc/examples] lxc-execute
-n p1 -- /bin/bash
lxc-execute: Operation not permitted - failed to clone
lxc-execute: failed to clone(0x6c02): Operation not permitted
lxc-execute: Operation not permitted - failed to fork into a new namespace
lxc-execute: failed to spawn 'p1'
> It may be worth teaching lxc_init a bit about unprivileged containers
> but besides that, if all I wanted to do was run a command using that
> container rootfs, it'd work.
>
> The rest I think looks good and hopefully we can drop quite a few of
> those before the 1.0 release. It shouldn't be too hard to get basic dir
> cloning working and a good chunk of the rest would get resolved if we
> had attach working.
>
> Ideally, we'd release with only the snapshot functions and the
> add/remove device function disabled as those simply aren't doable at
> this point.
>
>> Signed-off-by: S.Çağlar Onur
>> ---
>> src/lxc/lxc_attach.c | 5
>> src/lxc/lxc_execute.c | 5
>> src/lxc/lxc_info.c | 20 +++--
>> src/lxc/lxccontainer.c | 78
>> ++
>> 4 files changed, 95 insertions(+), 13 deletions(-)
>>
>> diff --git a/src/lxc/lxc_attach.c b/src/lxc/lxc_attach.c
>> index 6744c05..1159d09 100644
>> --- a/src/lxc/lxc_attach.c
>> +++ b/src/lxc/lxc_attach.c
>> @@ -188,6 +188,11 @@ int main(int argc, char *argv[])
>> lxc_attach_options_t attach_options = LXC_ATTACH_OPTIONS_DEFAULT;
>> lxc_attach_command_t command;
>>
>> +if (geteuid() != 0) {
>> +ERROR("lxc-attach is not currently supported with
>> unprivileged containers");
>> +return -1;
>> +}
>> +
>> ret = lxc_caps_init();
>> if (ret)
>> return ret;
>> diff --git a/src/lxc/lxc_execute.c b/src/lxc/lxc_execute.c
>> index 6a54bf6..8177ed3 100644
>> --- a/src/lxc/lxc_execute.c
>> +++ b/src/lxc/lxc_execute.c
>> @@ -92,6 +92,11 @@ int main(int argc, char *argv[])
>> char *rcfile;
>> struct lxc_conf *conf;
>>
>> +if (geteuid() != 0) {
>> +ERROR("lxc-execute is not currently supported with
>> unprivileged containers");
>> +return -1;
>> +}
>> +
>> lxc_list_init(&defines);
>>
>> if (lxc_caps_init())
>> diff --git a/src/lxc/lxc_info.c b/src/lxc/lxc_info.c
>> index b515087..0990036 100644
>> --- a/src/lxc/lxc_info.c
>> +++ b/src/lxc/lxc_info.c
>> @@ -310,15 +310,19 @@ static int print_info(const char *name, const char
>> *lxcpath)
>> }
>>
>> if (ips) {
>> - char **addresses = c->get_ips(c, NULL, NULL, 0);
>> - if (addresses) {
>> - char *address;
>> - i = 0;
>> - while (addresses[i]) {
>> - address = addresses[i];
>> - print_info_msg_str("IP:", address);
>> - i++;
>> + if (geteuid() == 0) {
>> + char **addresses = c->get_ips(c, NULL, NULL, 0);
>> + if (addresses) {
>> + char *address;
>> + i = 0;
>> + while (addresses[i]) {
>> + address = addresses[i];
>> +
Re: [lxc-devel] [PATCH] handle unprivileged user calls more gracefully (v2)
On Fri, Jan 17, 2014 at 11:34:50PM -0500, S.Çağlar Onur wrote:
> Return an error if the function is not supposed to be called by an
> unprivileged user.
> Otherwise those calls fail in the middle of their execution with different
> reasons.
>
> changes since v1:
> - am_unpriv is now a simple geteuid check,
> - API functions are now providing error messages,
> - lxc-info, lxc-attach and lxc-execute are now checking geteuid
>
That looks much better to me, though I disagree that lxc-execute doesn't
work. It certainly is a bit restricted compared ot its system
equivalent, but all of those limitations will be the same as with
lxc-start.
stgraber@castiana:~$ lxc-execute -n p1 -- /bin/bash
lxc-init: failed to mount /proc : Device or resource busy
lxc-init: failed to mount /dev/shm : No such file or directory
root@p1:/#
It may be worth teaching lxc_init a bit about unprivileged containers
but besides that, if all I wanted to do was run a command using that
container rootfs, it'd work.
The rest I think looks good and hopefully we can drop quite a few of
those before the 1.0 release. It shouldn't be too hard to get basic dir
cloning working and a good chunk of the rest would get resolved if we
had attach working.
Ideally, we'd release with only the snapshot functions and the
add/remove device function disabled as those simply aren't doable at
this point.
> Signed-off-by: S.Çağlar Onur
> ---
> src/lxc/lxc_attach.c | 5
> src/lxc/lxc_execute.c | 5
> src/lxc/lxc_info.c | 20 +++--
> src/lxc/lxccontainer.c | 78
> ++
> 4 files changed, 95 insertions(+), 13 deletions(-)
>
> diff --git a/src/lxc/lxc_attach.c b/src/lxc/lxc_attach.c
> index 6744c05..1159d09 100644
> --- a/src/lxc/lxc_attach.c
> +++ b/src/lxc/lxc_attach.c
> @@ -188,6 +188,11 @@ int main(int argc, char *argv[])
> lxc_attach_options_t attach_options = LXC_ATTACH_OPTIONS_DEFAULT;
> lxc_attach_command_t command;
>
> +if (geteuid() != 0) {
> +ERROR("lxc-attach is not currently supported with
> unprivileged containers");
> +return -1;
> +}
> +
> ret = lxc_caps_init();
> if (ret)
> return ret;
> diff --git a/src/lxc/lxc_execute.c b/src/lxc/lxc_execute.c
> index 6a54bf6..8177ed3 100644
> --- a/src/lxc/lxc_execute.c
> +++ b/src/lxc/lxc_execute.c
> @@ -92,6 +92,11 @@ int main(int argc, char *argv[])
> char *rcfile;
> struct lxc_conf *conf;
>
> +if (geteuid() != 0) {
> +ERROR("lxc-execute is not currently supported with
> unprivileged containers");
> +return -1;
> +}
> +
> lxc_list_init(&defines);
>
> if (lxc_caps_init())
> diff --git a/src/lxc/lxc_info.c b/src/lxc/lxc_info.c
> index b515087..0990036 100644
> --- a/src/lxc/lxc_info.c
> +++ b/src/lxc/lxc_info.c
> @@ -310,15 +310,19 @@ static int print_info(const char *name, const char
> *lxcpath)
> }
>
> if (ips) {
> - char **addresses = c->get_ips(c, NULL, NULL, 0);
> - if (addresses) {
> - char *address;
> - i = 0;
> - while (addresses[i]) {
> - address = addresses[i];
> - print_info_msg_str("IP:", address);
> - i++;
> + if (geteuid() == 0) {
> + char **addresses = c->get_ips(c, NULL, NULL, 0);
> + if (addresses) {
> + char *address;
> + i = 0;
> + while (addresses[i]) {
> + address = addresses[i];
> + print_info_msg_str("IP:", address);
> + i++;
> + }
> }
> + } else {
> + print_info_msg_str("IP:", "UNKNOWN");
> }
> }
>
> diff --git a/src/lxc/lxccontainer.c b/src/lxc/lxccontainer.c
> index 0bebdff..368cb46 100644
> --- a/src/lxc/lxccontainer.c
> +++ b/src/lxc/lxccontainer.c
> @@ -62,8 +62,14 @@
>
> #define MAX_BUFFER 4096
>
> +#define NOT_SUPPORTED_ERROR "the requested function %s is not currently
> supported with unprivileged containers"
> +
> lxc_log_define(lxc_container, lxc);
>
> +inline static bool am_unpriv() {
> + return geteuid() != 0;
> +}
> +
> static bool file_exists(const char *f)
> {
> struct stat statbuf;
> @@ -1489,6 +1495,11 @@ static char** lxcapi_get_interfaces(struct
> lxc_container *c)
> char **interfaces = NULL;
> int old_netns = -1, new_netns = -1;
>
> + if (am_unpriv()) {
> + ERROR(NOT_SUPPORTED_ERROR, __FUNCTION__);
> + goto out;
> + }
> +
> if (!enter_to_ns(c, &old_netns, &new_netns))
> goto out;
>
> @@ -1538,6 +1549,11 @@ static ch
Re: [lxc-devel] [PATCH] handle unprivileged user calls more gracefully
On Fri, Jan 17, 2014 at 7:34 PM, Stéphane Graber wrote:
> On Fri, Jan 17, 2014 at 07:27:03PM -0500, S.Çağlar Onur wrote:
>> Hey Stéphane,
>>
>> On Fri, Jan 17, 2014 at 3:18 PM, Stéphane Graber wrote:
>> > On Fri, Jan 17, 2014 at 03:01:46PM -0500, S.Çağlar Onur wrote:
>> >> Return an error if the function is not supposed to be called by an
>> >> unprivileged user.
>> >> Otherwise those calls fail in the middle of their execution with
>> >> different reasons.
>> >>
>> >> Signed-off-by: S.Çağlar Onur
>> >
>> > Hmm, so I have mixed feelings about this. I certainly understand the
>> > reason for wanting this and I was actually considering a similar patch
>> > after seeing lxc-info complain quite a bit about unprivileged
>> > containers.
>> >
>> > However, I think API calls should print an error message indicating that
>> > the requested function isn't currently supported with unprivileged
>> > containers and the individual callers should themselves check whether
>> > they're running unprivileged and show something more relevant to the
>> > user.
>>
>> This is what I'm doing in go bindings but we still need to handle
>> those cases in the C API itself as I believe there will be people
>> directly using it. I can definitely add some error messages to
>> unprivileged cases to make it clear to the caller why the call failed.
>
> Right, the one place I can think of at least is lxc-info, so ideally
> we'd want to have it be unprivilege containers aware at the same time as
> we change the API.
>
>> On the other hand, I see this patch as an intermediate step as I
>> believe some of those functions could be made functional with
>> unprivileged containers as well.
>
> Agreed, at least anything relying on setns should be fixable.
> It's possible/likely that doing the right sequence of setns and remount
> we could make this work, if not, then we'd have to get a kernel patch.
>
> In any case, I think getting working attach by 1.0 is a very worthwhile
> goal as it's the main issue I see day to day when working with
> unprivileged containers.
>
>>
>> > Specifically, my concern with this is that lxc-ls and lxc-info will now
>> > report that a container doesn't have any interface or ip address, which
>> > is just wrong. Instead the user should be told that those are unknown as
>> > lxc-ls is currently doing.
>> >
>> > Also, the condition for am_unpriv seems a bit odd to me as it'd indicate
>> > that I can do:
>> > - p1 = Container("p1")
>> > - p1.start()
>> > - p1.clear_config_item("lxc.id_map")
>> > - p1.get_ips()
>> >
>> > And that'd workaround your test.
>> >
>> > Why can't it simply be: "return getuid() != 0;"?
>> >
>> > And if it ends up being just that, do we really need an am_unpriv(c)
>> > function when we can simply call "if (geteuid())"?
>>
>> I guess we can just call geteuid as you suggested, that am_priv code
>> was already in the code so I just reused it :)
>
> Yeah, I think it'd be easier to just call geteuid() in those cases and
> throwing an ERROR() with a relevant message for the given API call.
>
> In practice we should never see any of those ERROR in the upstream tools
> as they should all be detecting this before the actual API call, so it's
> just a safety net for external users.
OK, v2 should be in the list soon, hopefully addressing those issues,
please let me know what you think.
>>
>> >> ---
>> >> src/lxc/lxccontainer.c | 33 -
>> >> 1 file changed, 28 insertions(+), 5 deletions(-)
>> >>
>> >> diff --git a/src/lxc/lxccontainer.c b/src/lxc/lxccontainer.c
>> >> index 0bebdff..8d49e94 100644
>> >> --- a/src/lxc/lxccontainer.c
>> >> +++ b/src/lxc/lxccontainer.c
>> >> @@ -64,6 +64,10 @@
>> >>
>> >> lxc_log_define(lxc_container, lxc);
>> >>
>> >> +static bool am_unpriv(struct lxc_container *c) {
>> >> + return c->lxc_conf && geteuid() != 0 &&
>> >> !lxc_list_empty(&c->lxc_conf->id_map);
>> >> +}
>> >> +
>> >> static bool file_exists(const char *f)
>> >> {
>> >> struct stat statbuf;
>> >> @@ -1489,6 +1493,9 @@ static char** lxcapi_get_interfaces(struct
>> >> lxc_container *c)
>> >> char **interfaces = NULL;
>> >> int old_netns = -1, new_netns = -1;
>> >>
>> >> + if (am_unpriv(c))
>> >> + goto out;
>> >> +
>> >> if (!enter_to_ns(c, &old_netns, &new_netns))
>> >> goto out;
>> >>
>> >> @@ -1538,6 +1545,9 @@ static char** lxcapi_get_ips(struct lxc_container
>> >> *c, const char* interface, con
>> >> char *address = NULL;
>> >> int old_netns = -1, new_netns = -1;
>> >>
>> >> + if (am_unpriv(c))
>> >> + goto out;
>> >> +
>> >> if (!enter_to_ns(c, &old_netns, &new_netns))
>> >> goto out;
>> >>
>> >> @@ -1818,7 +1828,7 @@ static int lxc_rmdir_onedev_wrapper(void *data)
>> >> static bool lxcapi_destroy(struct lxc_container *c)
>> >> {
>> >> struct bdev *r = NULL;
>> >> - bool bret = false, am_unpriv;
>> >> + bool bret = false;
>> >> int ret;
>>
[lxc-devel] [PATCH] handle unprivileged user calls more gracefully (v2)
Return an error if the function is not supposed to be called by an unprivileged
user.
Otherwise those calls fail in the middle of their execution with different
reasons.
changes since v1:
- am_unpriv is now a simple geteuid check,
- API functions are now providing error messages,
- lxc-info, lxc-attach and lxc-execute are now checking geteuid
Signed-off-by: S.Çağlar Onur
---
src/lxc/lxc_attach.c | 5
src/lxc/lxc_execute.c | 5
src/lxc/lxc_info.c | 20 +++--
src/lxc/lxccontainer.c | 78 ++
4 files changed, 95 insertions(+), 13 deletions(-)
diff --git a/src/lxc/lxc_attach.c b/src/lxc/lxc_attach.c
index 6744c05..1159d09 100644
--- a/src/lxc/lxc_attach.c
+++ b/src/lxc/lxc_attach.c
@@ -188,6 +188,11 @@ int main(int argc, char *argv[])
lxc_attach_options_t attach_options = LXC_ATTACH_OPTIONS_DEFAULT;
lxc_attach_command_t command;
+if (geteuid() != 0) {
+ERROR("lxc-attach is not currently supported with unprivileged
containers");
+return -1;
+}
+
ret = lxc_caps_init();
if (ret)
return ret;
diff --git a/src/lxc/lxc_execute.c b/src/lxc/lxc_execute.c
index 6a54bf6..8177ed3 100644
--- a/src/lxc/lxc_execute.c
+++ b/src/lxc/lxc_execute.c
@@ -92,6 +92,11 @@ int main(int argc, char *argv[])
char *rcfile;
struct lxc_conf *conf;
+if (geteuid() != 0) {
+ERROR("lxc-execute is not currently supported with
unprivileged containers");
+return -1;
+}
+
lxc_list_init(&defines);
if (lxc_caps_init())
diff --git a/src/lxc/lxc_info.c b/src/lxc/lxc_info.c
index b515087..0990036 100644
--- a/src/lxc/lxc_info.c
+++ b/src/lxc/lxc_info.c
@@ -310,15 +310,19 @@ static int print_info(const char *name, const char
*lxcpath)
}
if (ips) {
- char **addresses = c->get_ips(c, NULL, NULL, 0);
- if (addresses) {
- char *address;
- i = 0;
- while (addresses[i]) {
- address = addresses[i];
- print_info_msg_str("IP:", address);
- i++;
+ if (geteuid() == 0) {
+ char **addresses = c->get_ips(c, NULL, NULL, 0);
+ if (addresses) {
+ char *address;
+ i = 0;
+ while (addresses[i]) {
+ address = addresses[i];
+ print_info_msg_str("IP:", address);
+ i++;
+ }
}
+ } else {
+ print_info_msg_str("IP:", "UNKNOWN");
}
}
diff --git a/src/lxc/lxccontainer.c b/src/lxc/lxccontainer.c
index 0bebdff..368cb46 100644
--- a/src/lxc/lxccontainer.c
+++ b/src/lxc/lxccontainer.c
@@ -62,8 +62,14 @@
#define MAX_BUFFER 4096
+#define NOT_SUPPORTED_ERROR "the requested function %s is not currently
supported with unprivileged containers"
+
lxc_log_define(lxc_container, lxc);
+inline static bool am_unpriv() {
+ return geteuid() != 0;
+}
+
static bool file_exists(const char *f)
{
struct stat statbuf;
@@ -1489,6 +1495,11 @@ static char** lxcapi_get_interfaces(struct lxc_container
*c)
char **interfaces = NULL;
int old_netns = -1, new_netns = -1;
+ if (am_unpriv()) {
+ ERROR(NOT_SUPPORTED_ERROR, __FUNCTION__);
+ goto out;
+ }
+
if (!enter_to_ns(c, &old_netns, &new_netns))
goto out;
@@ -1538,6 +1549,11 @@ static char** lxcapi_get_ips(struct lxc_container *c,
const char* interface, con
char *address = NULL;
int old_netns = -1, new_netns = -1;
+ if (am_unpriv()) {
+ ERROR(NOT_SUPPORTED_ERROR, __FUNCTION__);
+ goto out;
+ }
+
if (!enter_to_ns(c, &old_netns, &new_netns))
goto out;
@@ -1818,7 +1834,7 @@ static int lxc_rmdir_onedev_wrapper(void *data)
static bool lxcapi_destroy(struct lxc_container *c)
{
struct bdev *r = NULL;
- bool bret = false, am_unpriv;
+ bool bret = false;
int ret;
if (!c || !lxcapi_is_defined(c))
@@ -1833,14 +1849,12 @@ static bool lxcapi_destroy(struct lxc_container *c)
goto out;
}
- am_unpriv = c->lxc_conf && geteuid() != 0 &&
!lxc_list_empty(&c->lxc_conf->id_map);
-
if (c->lxc_conf && has_snapshots(c)) {
ERROR("container %s has dependent snapshots", c->name);
goto out;
}
- if (!am_unpriv && c->lxc_conf->rootfs.path &&
c->lxc_conf->rootfs.mount) {
+ if (!am_unpriv() && c->lxc_conf->rootfs.path &&
c->lxc_conf->rootfs.
Re: [lxc-devel] [PATCH] handle unprivileged user calls more gracefully
On Fri, Jan 17, 2014 at 07:27:03PM -0500, S.Çağlar Onur wrote:
> Hey Stéphane,
>
> On Fri, Jan 17, 2014 at 3:18 PM, Stéphane Graber wrote:
> > On Fri, Jan 17, 2014 at 03:01:46PM -0500, S.Çağlar Onur wrote:
> >> Return an error if the function is not supposed to be called by an
> >> unprivileged user.
> >> Otherwise those calls fail in the middle of their execution with different
> >> reasons.
> >>
> >> Signed-off-by: S.Çağlar Onur
> >
> > Hmm, so I have mixed feelings about this. I certainly understand the
> > reason for wanting this and I was actually considering a similar patch
> > after seeing lxc-info complain quite a bit about unprivileged
> > containers.
> >
> > However, I think API calls should print an error message indicating that
> > the requested function isn't currently supported with unprivileged
> > containers and the individual callers should themselves check whether
> > they're running unprivileged and show something more relevant to the
> > user.
>
> This is what I'm doing in go bindings but we still need to handle
> those cases in the C API itself as I believe there will be people
> directly using it. I can definitely add some error messages to
> unprivileged cases to make it clear to the caller why the call failed.
Right, the one place I can think of at least is lxc-info, so ideally
we'd want to have it be unprivilege containers aware at the same time as
we change the API.
> On the other hand, I see this patch as an intermediate step as I
> believe some of those functions could be made functional with
> unprivileged containers as well.
Agreed, at least anything relying on setns should be fixable.
It's possible/likely that doing the right sequence of setns and remount
we could make this work, if not, then we'd have to get a kernel patch.
In any case, I think getting working attach by 1.0 is a very worthwhile
goal as it's the main issue I see day to day when working with
unprivileged containers.
>
> > Specifically, my concern with this is that lxc-ls and lxc-info will now
> > report that a container doesn't have any interface or ip address, which
> > is just wrong. Instead the user should be told that those are unknown as
> > lxc-ls is currently doing.
> >
> > Also, the condition for am_unpriv seems a bit odd to me as it'd indicate
> > that I can do:
> > - p1 = Container("p1")
> > - p1.start()
> > - p1.clear_config_item("lxc.id_map")
> > - p1.get_ips()
> >
> > And that'd workaround your test.
> >
> > Why can't it simply be: "return getuid() != 0;"?
> >
> > And if it ends up being just that, do we really need an am_unpriv(c)
> > function when we can simply call "if (geteuid())"?
>
> I guess we can just call geteuid as you suggested, that am_priv code
> was already in the code so I just reused it :)
Yeah, I think it'd be easier to just call geteuid() in those cases and
throwing an ERROR() with a relevant message for the given API call.
In practice we should never see any of those ERROR in the upstream tools
as they should all be detecting this before the actual API call, so it's
just a safety net for external users.
>
> >> ---
> >> src/lxc/lxccontainer.c | 33 -
> >> 1 file changed, 28 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/src/lxc/lxccontainer.c b/src/lxc/lxccontainer.c
> >> index 0bebdff..8d49e94 100644
> >> --- a/src/lxc/lxccontainer.c
> >> +++ b/src/lxc/lxccontainer.c
> >> @@ -64,6 +64,10 @@
> >>
> >> lxc_log_define(lxc_container, lxc);
> >>
> >> +static bool am_unpriv(struct lxc_container *c) {
> >> + return c->lxc_conf && geteuid() != 0 &&
> >> !lxc_list_empty(&c->lxc_conf->id_map);
> >> +}
> >> +
> >> static bool file_exists(const char *f)
> >> {
> >> struct stat statbuf;
> >> @@ -1489,6 +1493,9 @@ static char** lxcapi_get_interfaces(struct
> >> lxc_container *c)
> >> char **interfaces = NULL;
> >> int old_netns = -1, new_netns = -1;
> >>
> >> + if (am_unpriv(c))
> >> + goto out;
> >> +
> >> if (!enter_to_ns(c, &old_netns, &new_netns))
> >> goto out;
> >>
> >> @@ -1538,6 +1545,9 @@ static char** lxcapi_get_ips(struct lxc_container
> >> *c, const char* interface, con
> >> char *address = NULL;
> >> int old_netns = -1, new_netns = -1;
> >>
> >> + if (am_unpriv(c))
> >> + goto out;
> >> +
> >> if (!enter_to_ns(c, &old_netns, &new_netns))
> >> goto out;
> >>
> >> @@ -1818,7 +1828,7 @@ static int lxc_rmdir_onedev_wrapper(void *data)
> >> static bool lxcapi_destroy(struct lxc_container *c)
> >> {
> >> struct bdev *r = NULL;
> >> - bool bret = false, am_unpriv;
> >> + bool bret = false;
> >> int ret;
> >>
> >> if (!c || !lxcapi_is_defined(c))
> >> @@ -1833,14 +1843,12 @@ static bool lxcapi_destroy(struct lxc_container *c)
> >> goto out;
> >> }
> >>
> >> - am_unpriv = c->lxc_conf && geteuid() != 0 &&
> >> !lxc_list_empty(&c->lxc_conf->id_map);
> >> -
> >> if
Re: [lxc-devel] [PATCH] handle unprivileged user calls more gracefully
Hey Stéphane,
On Fri, Jan 17, 2014 at 3:18 PM, Stéphane Graber wrote:
> On Fri, Jan 17, 2014 at 03:01:46PM -0500, S.Çağlar Onur wrote:
>> Return an error if the function is not supposed to be called by an
>> unprivileged user.
>> Otherwise those calls fail in the middle of their execution with different
>> reasons.
>>
>> Signed-off-by: S.Çağlar Onur
>
> Hmm, so I have mixed feelings about this. I certainly understand the
> reason for wanting this and I was actually considering a similar patch
> after seeing lxc-info complain quite a bit about unprivileged
> containers.
>
> However, I think API calls should print an error message indicating that
> the requested function isn't currently supported with unprivileged
> containers and the individual callers should themselves check whether
> they're running unprivileged and show something more relevant to the
> user.
This is what I'm doing in go bindings but we still need to handle
those cases in the C API itself as I believe there will be people
directly using it. I can definitely add some error messages to
unprivileged cases to make it clear to the caller why the call failed.
On the other hand, I see this patch as an intermediate step as I
believe some of those functions could be made functional with
unprivileged containers as well.
> Specifically, my concern with this is that lxc-ls and lxc-info will now
> report that a container doesn't have any interface or ip address, which
> is just wrong. Instead the user should be told that those are unknown as
> lxc-ls is currently doing.
>
> Also, the condition for am_unpriv seems a bit odd to me as it'd indicate
> that I can do:
> - p1 = Container("p1")
> - p1.start()
> - p1.clear_config_item("lxc.id_map")
> - p1.get_ips()
>
> And that'd workaround your test.
>
> Why can't it simply be: "return getuid() != 0;"?
>
> And if it ends up being just that, do we really need an am_unpriv(c)
> function when we can simply call "if (geteuid())"?
I guess we can just call geteuid as you suggested, that am_priv code
was already in the code so I just reused it :)
>> ---
>> src/lxc/lxccontainer.c | 33 -
>> 1 file changed, 28 insertions(+), 5 deletions(-)
>>
>> diff --git a/src/lxc/lxccontainer.c b/src/lxc/lxccontainer.c
>> index 0bebdff..8d49e94 100644
>> --- a/src/lxc/lxccontainer.c
>> +++ b/src/lxc/lxccontainer.c
>> @@ -64,6 +64,10 @@
>>
>> lxc_log_define(lxc_container, lxc);
>>
>> +static bool am_unpriv(struct lxc_container *c) {
>> + return c->lxc_conf && geteuid() != 0 &&
>> !lxc_list_empty(&c->lxc_conf->id_map);
>> +}
>> +
>> static bool file_exists(const char *f)
>> {
>> struct stat statbuf;
>> @@ -1489,6 +1493,9 @@ static char** lxcapi_get_interfaces(struct
>> lxc_container *c)
>> char **interfaces = NULL;
>> int old_netns = -1, new_netns = -1;
>>
>> + if (am_unpriv(c))
>> + goto out;
>> +
>> if (!enter_to_ns(c, &old_netns, &new_netns))
>> goto out;
>>
>> @@ -1538,6 +1545,9 @@ static char** lxcapi_get_ips(struct lxc_container *c,
>> const char* interface, con
>> char *address = NULL;
>> int old_netns = -1, new_netns = -1;
>>
>> + if (am_unpriv(c))
>> + goto out;
>> +
>> if (!enter_to_ns(c, &old_netns, &new_netns))
>> goto out;
>>
>> @@ -1818,7 +1828,7 @@ static int lxc_rmdir_onedev_wrapper(void *data)
>> static bool lxcapi_destroy(struct lxc_container *c)
>> {
>> struct bdev *r = NULL;
>> - bool bret = false, am_unpriv;
>> + bool bret = false;
>> int ret;
>>
>> if (!c || !lxcapi_is_defined(c))
>> @@ -1833,14 +1843,12 @@ static bool lxcapi_destroy(struct lxc_container *c)
>> goto out;
>> }
>>
>> - am_unpriv = c->lxc_conf && geteuid() != 0 &&
>> !lxc_list_empty(&c->lxc_conf->id_map);
>> -
>> if (c->lxc_conf && has_snapshots(c)) {
>> ERROR("container %s has dependent snapshots", c->name);
>> goto out;
>> }
>>
>> - if (!am_unpriv && c->lxc_conf->rootfs.path &&
>> c->lxc_conf->rootfs.mount) {
>> + if (!am_unpriv(c) && c->lxc_conf->rootfs.path &&
>> c->lxc_conf->rootfs.mount) {
>> r = bdev_init(c->lxc_conf->rootfs.path,
>> c->lxc_conf->rootfs.mount, NULL);
>> if (r) {
>> if (r->ops->destroy(r) < 0) {
>> @@ -1857,7 +1865,7 @@ static bool lxcapi_destroy(struct lxc_container *c)
>> const char *p1 = lxcapi_get_config_path(c);
>> char *path = alloca(strlen(p1) + strlen(c->name) + 2);
>> sprintf(path, "%s/%s", p1, c->name);
>> - if (am_unpriv)
>> + if (am_unpriv(c))
>> ret = userns_exec_1(c->lxc_conf, lxc_rmdir_onedev_wrapper,
>> path);
>> else
>> ret = lxc_rmdir_onedev(path);
>> @@ -2406,6 +2414,9 @@ static struct lxc_container *lxcapi_clone(struct
>> lxc_container *c, const char *n
>> if (!c || !c->is_defined(c))
>> return NULL;
>>
>> + if (am
[lxc-devel] [lxc/lxc] adade8: lxc-usernsexec: add a manpage
Branch: refs/heads/master Home: https://github.com/lxc/lxc Commit: adade80c7e74c5185f63ff009116bf9d30c79876 https://github.com/lxc/lxc/commit/adade80c7e74c5185f63ff009116bf9d30c79876 Author: Serge Hallyn Date: 2014-01-17 (Fri, 17 Jan 2014) Changed paths: M configure.ac M doc/Makefile.am A doc/lxc-usernsexec.sgml.in M src/lxc/lxc_usernsexec.c Log Message: --- lxc-usernsexec: add a manpage and fix the help output in the program Signed-off-by: Serge Hallyn Acked-by: Stéphane Graber ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 1/1] lxc-usernsexec: add a manpage
On Fri, Jan 17, 2014 at 03:15:45PM -0600, Serge Hallyn wrote:
> and fix the help output in the program
>
> Signed-off-by: Serge Hallyn
Acked-by: Stéphane Graber
> ---
> configure.ac | 1 +
> doc/Makefile.am| 1 +
> doc/lxc-usernsexec.sgml.in | 156
> +
> src/lxc/lxc_usernsexec.c | 3 +-
> 4 files changed, 159 insertions(+), 2 deletions(-)
> create mode 100644 doc/lxc-usernsexec.sgml.in
>
> diff --git a/configure.ac b/configure.ac
> index d8be165..8e1c198 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -592,6 +592,7 @@ AC_CONFIG_FILES([
> doc/lxc-unfreeze.sgml
> doc/lxc-unshare.sgml
> doc/lxc-user-nic.sgml
> + doc/lxc-usernsexec.sgml
> doc/lxc-version.sgml
> doc/lxc-wait.sgml
>
> diff --git a/doc/Makefile.am b/doc/Makefile.am
> index e87c2f8..f548238 100644
> --- a/doc/Makefile.am
> +++ b/doc/Makefile.am
> @@ -38,6 +38,7 @@ man_MANS = \
> lxc-unfreeze.1 \
> lxc-unshare.1 \
> lxc-user-nic.1 \
> + lxc-usernsexec.1 \
> lxc-version.1 \
> lxc-wait.1 \
> \
> diff --git a/doc/lxc-usernsexec.sgml.in b/doc/lxc-usernsexec.sgml.in
> new file mode 100644
> index 000..ca55ed8
> --- /dev/null
> +++ b/doc/lxc-usernsexec.sgml.in
> @@ -0,0 +1,156 @@
> +
> +
> + +
> +
> +
> +]>
> +
> +
> +
> + @LXC_GENERATE_DATE@
> +
> +
> +lxc-usernsexec
> +1
> +
> +
> +
> +lxc-usernsexec
> +
> +
> + Run a task as root in a new user namespace.
> +
> +
> +
> +
> +
> + lxc-unshare
> + -m uid-map
> + -- command
> +
> +
> +
> +
> +Description
> +
> +
> + lxc-usernsexec can be used to run a task as root
> + in a new user namespace.
> +
> +
> +
> +
> +
> +
> +Options
> +
> +
> +
> +
> +
> + -m uid-map
> +
> +
> +
> + The uid map to use in the user namespace. Each map consists of
> + four colon-separate values. First a character 'u', 'g' or 'b' to
> + specify whether this map perttains to user ids, group ids, or
> + both; next the first userid in the user namespace; next the
> + first userid as seen on the host; and finally the number of
> + ids to be mapped.
> +
> +
> + More than one map can be specified. If no map is
> + specified, then by default the full uid and gid ranges granted
> + by /etc/subuid and /etc/subgid will be mapped to the
> + uids and gids starting at 0 in the container.
> +
> +
> + Note that lxc-usernsexec always tries
> + to setuid and setgid to 0 in the namespace. Therefore uid 0 in
> + the namespace must be mapped.
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +Examples
> +
> +To spawn a shell with the full allotted subuids mapped into
> + the container, use
> +
> + lxc-usernsexec
> +
> + To run a different shell than /bin/sh, use
> +
> + lxc-usernsexec -- /bin/bash
> +
> +
> +
> + If your user id is 1000, root in a container is mapped to 19, and
> + you wish to chown a file you own to root in the container, you can use:
> +
> + lxc-usernsexec -m b:0:1000:1 -m b:1:19:1 -- /bin/chown 1:1 $file
> +
> + This maps your userid to root in the user namespace, and 19 to uid
> 1.
> + Since root in the user namespace is privileged over all userids mapped
> + into the namespace, you are allowed to change the file ownership, which
> + you could not do on the host using a simple chown.
> +
> +
> +
> + &seealso;
> +
> +
> +Author
> +Serge Hallyn serge.hal...@ubuntu.com
> +
> +
> +
> +
> +
> diff --git a/src/lxc/lxc_usernsexec.c b/src/lxc/lxc_usernsexec.c
> index 35cd473..8335725 100644
> --- a/src/lxc/lxc_usernsexec.c
> +++ b/src/lxc/lxc_usernsexec.c
> @@ -47,8 +47,7 @@ int unshare(int flags);
>
> static void usage(const char *name)
> {
> - printf("usage: %s [-h] [-c] [-mnuUip] [-P ]"
> - "[command [arg ..]]\n", name);
> + printf("usage: %s [-h] [-m ] -- [command [arg ..]]\n", name);
> printf("\n");
> printf(" -hthis message\n");
> printf("\n");
> --
> 1.8.5.2
>
> ___
> lxc-devel mailing list
> lxc-devel@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-devel
--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
signature.asc
Description: Digital signature
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] Containers do not start with lxc-1.0.0.beta2 on RHEL-6.5
Quoting Robert Vogelgesang (vo...@users.sourceforge.net):
> Hello all,
>
> since yesterday I'm testing lxc-1.0.0.beta2 on a RHEL-6.5, but I
> failed to get any container to start.
>
> I've set up a RHEL-6.5 test server with the "cgconfig" service enabled
> in default configuration. When I try to start a container (with root
> privileges), I get:
>
> # lxc-start -n test -d -o lxc-start.log -l DEBUG
> lxc-start: command get_cgroup failed to receive response
>
> The container did not start, and lxc-start.log has the following ERRORs:
> (leading whitespace trimmed)
>
> lxc-start 1389968577.048 ERRORlxc_cgroup - Could not set clone_children
> to 1 for cpuset hierarchy in parent cgroup.
> lxc-start 1389968577.048 ERRORlxc_cgroup - Device or resource busy -
> cgroup_rmdir: failed to delete /cgroup/blkio/
> lxc-start 1389968577.048 ERRORlxc_cgroup - Device or resource busy -
> cgroup_rmdir: failed to delete /cgroup/net_cls/
> lxc-start 1389968577.048 ERRORlxc_cgroup - Device or resource busy -
> cgroup_rmdir: failed to delete /cgroup/freezer/
> lxc-start 1389968577.048 ERRORlxc_cgroup - Device or resource busy -
> cgroup_rmdir: failed to delete /cgroup/devices/
> lxc-start 1389968577.048 ERRORlxc_cgroup - Device or resource busy -
> cgroup_rmdir: failed to delete /cgroup/memory/
> lxc-start 1389968577.048 ERRORlxc_cgroup - Device or resource busy -
> cgroup_rmdir: failed to delete /cgroup/cpuacct/
> lxc-start 1389968577.049 ERRORlxc_cgroup - Device or resource busy -
> cgroup_rmdir: failed to delete /cgroup/cpu/
> lxc-start 1389968577.049 ERRORlxc_cgroup - Device or resource busy -
> cgroup_rmdir: failed to delete /cgroup/cpuset/
> lxc-start 1389968577.049 ERRORlxc_start - failed to create cgroups for
> 'test'
> lxc-start 1389968577.078 ERRORlxc_start - failed to spawn 'test'
> lxc-start 1389968577.079 ERRORlxc_commands - command get_cgroup failed to
> receive response
>
>
> The first error comes from cgroup.c:lxc_cgroup_create(). When comparing
> this with cgroup.c:set_clone_children() from lxc-0.9.0 I saw that 0.9.0
> ignored errors when setting clone_children, and so I patched
> cgroup.c:lxc_cgroup_create() to do the same. But the container still did
> not start. The errors in lxc-start.log were now:
>
> lxc-start 1389980209.248 ERRORlxc_cgroup - No space left on device -
> Could not add pid 21347 to cgroup /lxc/test: internal error
> lxc-start 1389980209.270 ERRORlxc_start - failed to spawn 'test'
> lxc-start 1389980209.271 ERRORlxc_commands - command get_cgroup failed to
> receive response
>
> Using strace(8), I found this:
> open("/cgroup/cpuset/lxc/test/tasks", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC,
> 0666) = 11
> write(11, "21347", 5) = -1 ENOSPC (No space left on device)
> close(11) = 0
>
> Switching back to lxc-0.9.0, this same container starts just fine.
>
> 0.9.0 has its own set of problems when used under RHEL-6.5, but containers
> do at least start - and can be shut down again. I had hoped that 1.0.0
> would resolve the issues of 0.9.0... (lxc-ps and lxc-netstat don't work)
>
> So, my first question would be: Is RHEL-6.5 (and CentOS 6.5, and others)
> a "supported" platform for lxc-1.0.0?
>
> And if so: What should I do to debug this further? Are there already
> some patches I could test?
Hi,
I'm not sure what's going on with the order of things for you, but I
can explain the errors from the low level.
When you're not allowed to set clone_children, it is likely because
there are already other child cgroups. You cannot change clone_children
in that case.
When you get -ENOSPC it is because clone_children was not set, so the
cpuset.mems and cpuset.cpus files were not initialized in the
container's cgroups. (I've always hated this behavior).
The *surest* way to avoid problems is to set up an early init job for
yourself which sets clone_children to 1 in the root cpuset cgroup.
-serge
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [PATCH 1/1] lxc-usernsexec: add a manpage
and fix the help output in the program
Signed-off-by: Serge Hallyn
---
configure.ac | 1 +
doc/Makefile.am| 1 +
doc/lxc-usernsexec.sgml.in | 156 +
src/lxc/lxc_usernsexec.c | 3 +-
4 files changed, 159 insertions(+), 2 deletions(-)
create mode 100644 doc/lxc-usernsexec.sgml.in
diff --git a/configure.ac b/configure.ac
index d8be165..8e1c198 100644
--- a/configure.ac
+++ b/configure.ac
@@ -592,6 +592,7 @@ AC_CONFIG_FILES([
doc/lxc-unfreeze.sgml
doc/lxc-unshare.sgml
doc/lxc-user-nic.sgml
+ doc/lxc-usernsexec.sgml
doc/lxc-version.sgml
doc/lxc-wait.sgml
diff --git a/doc/Makefile.am b/doc/Makefile.am
index e87c2f8..f548238 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -38,6 +38,7 @@ man_MANS = \
lxc-unfreeze.1 \
lxc-unshare.1 \
lxc-user-nic.1 \
+ lxc-usernsexec.1 \
lxc-version.1 \
lxc-wait.1 \
\
diff --git a/doc/lxc-usernsexec.sgml.in b/doc/lxc-usernsexec.sgml.in
new file mode 100644
index 000..ca55ed8
--- /dev/null
+++ b/doc/lxc-usernsexec.sgml.in
@@ -0,0 +1,156 @@
+
+
+
+
+]>
+
+
+
+ @LXC_GENERATE_DATE@
+
+
+lxc-usernsexec
+1
+
+
+
+lxc-usernsexec
+
+
+ Run a task as root in a new user namespace.
+
+
+
+
+
+ lxc-unshare
+ -m uid-map
+ -- command
+
+
+
+
+Description
+
+
+ lxc-usernsexec can be used to run a task as root
+ in a new user namespace.
+
+
+
+
+
+
+Options
+
+
+
+
+
+ -m uid-map
+
+
+
+ The uid map to use in the user namespace. Each map consists of
+ four colon-separate values. First a character 'u', 'g' or 'b' to
+ specify whether this map perttains to user ids, group ids, or
+ both; next the first userid in the user namespace; next the
+ first userid as seen on the host; and finally the number of
+ ids to be mapped.
+
+
+ More than one map can be specified. If no map is
+ specified, then by default the full uid and gid ranges granted
+ by /etc/subuid and /etc/subgid will be mapped to the
+ uids and gids starting at 0 in the container.
+
+
+ Note that lxc-usernsexec always tries
+ to setuid and setgid to 0 in the namespace. Therefore uid 0 in
+ the namespace must be mapped.
+
+
+
+
+
+
+
+
+
+
+Examples
+
+To spawn a shell with the full allotted subuids mapped into
+ the container, use
+
+ lxc-usernsexec
+
+ To run a different shell than /bin/sh, use
+
+ lxc-usernsexec -- /bin/bash
+
+
+
+ If your user id is 1000, root in a container is mapped to 19, and
+ you wish to chown a file you own to root in the container, you can use:
+
+ lxc-usernsexec -m b:0:1000:1 -m b:1:19:1 -- /bin/chown 1:1 $file
+
+ This maps your userid to root in the user namespace, and 19 to uid
1.
+ Since root in the user namespace is privileged over all userids mapped
+ into the namespace, you are allowed to change the file ownership, which
+ you could not do on the host using a simple chown.
+
+
+
+ &seealso;
+
+
+Author
+Serge Hallyn serge.hal...@ubuntu.com
+
+
+
+
+
diff --git a/src/lxc/lxc_usernsexec.c b/src/lxc/lxc_usernsexec.c
index 35cd473..8335725 100644
--- a/src/lxc/lxc_usernsexec.c
+++ b/src/lxc/lxc_usernsexec.c
@@ -47,8 +47,7 @@ int unshare(int flags);
static void usage(const char *name)
{
- printf("usage: %s [-h] [-c] [-mnuUip] [-P ]"
- "[command [arg ..]]\n", name);
+ printf("usage: %s [-h] [-m ] -- [command [arg ..]]\n", name);
printf("\n");
printf(" -hthis message\n");
printf("\n");
--
1.8.5.2
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] handle unprivileged user calls more gracefully
On Fri, Jan 17, 2014 at 03:01:46PM -0500, S.Çağlar Onur wrote:
> Return an error if the function is not supposed to be called by an
> unprivileged user.
> Otherwise those calls fail in the middle of their execution with different
> reasons.
>
> Signed-off-by: S.Çağlar Onur
Hmm, so I have mixed feelings about this. I certainly understand the
reason for wanting this and I was actually considering a similar patch
after seeing lxc-info complain quite a bit about unprivileged
containers.
However, I think API calls should print an error message indicating that
the requested function isn't currently supported with unprivileged
containers and the individual callers should themselves check whether
they're running unprivileged and show something more relevant to the
user.
Specifically, my concern with this is that lxc-ls and lxc-info will now
report that a container doesn't have any interface or ip address, which
is just wrong. Instead the user should be told that those are unknown as
lxc-ls is currently doing.
Also, the condition for am_unpriv seems a bit odd to me as it'd indicate
that I can do:
- p1 = Container("p1")
- p1.start()
- p1.clear_config_item("lxc.id_map")
- p1.get_ips()
And that'd workaround your test.
Why can't it simply be: "return getuid() != 0;"?
And if it ends up being just that, do we really need an am_unpriv(c)
function when we can simply call "if (geteuid())"?
> ---
> src/lxc/lxccontainer.c | 33 -
> 1 file changed, 28 insertions(+), 5 deletions(-)
>
> diff --git a/src/lxc/lxccontainer.c b/src/lxc/lxccontainer.c
> index 0bebdff..8d49e94 100644
> --- a/src/lxc/lxccontainer.c
> +++ b/src/lxc/lxccontainer.c
> @@ -64,6 +64,10 @@
>
> lxc_log_define(lxc_container, lxc);
>
> +static bool am_unpriv(struct lxc_container *c) {
> + return c->lxc_conf && geteuid() != 0 &&
> !lxc_list_empty(&c->lxc_conf->id_map);
> +}
> +
> static bool file_exists(const char *f)
> {
> struct stat statbuf;
> @@ -1489,6 +1493,9 @@ static char** lxcapi_get_interfaces(struct
> lxc_container *c)
> char **interfaces = NULL;
> int old_netns = -1, new_netns = -1;
>
> + if (am_unpriv(c))
> + goto out;
> +
> if (!enter_to_ns(c, &old_netns, &new_netns))
> goto out;
>
> @@ -1538,6 +1545,9 @@ static char** lxcapi_get_ips(struct lxc_container *c,
> const char* interface, con
> char *address = NULL;
> int old_netns = -1, new_netns = -1;
>
> + if (am_unpriv(c))
> + goto out;
> +
> if (!enter_to_ns(c, &old_netns, &new_netns))
> goto out;
>
> @@ -1818,7 +1828,7 @@ static int lxc_rmdir_onedev_wrapper(void *data)
> static bool lxcapi_destroy(struct lxc_container *c)
> {
> struct bdev *r = NULL;
> - bool bret = false, am_unpriv;
> + bool bret = false;
> int ret;
>
> if (!c || !lxcapi_is_defined(c))
> @@ -1833,14 +1843,12 @@ static bool lxcapi_destroy(struct lxc_container *c)
> goto out;
> }
>
> - am_unpriv = c->lxc_conf && geteuid() != 0 &&
> !lxc_list_empty(&c->lxc_conf->id_map);
> -
> if (c->lxc_conf && has_snapshots(c)) {
> ERROR("container %s has dependent snapshots", c->name);
> goto out;
> }
>
> - if (!am_unpriv && c->lxc_conf->rootfs.path &&
> c->lxc_conf->rootfs.mount) {
> + if (!am_unpriv(c) && c->lxc_conf->rootfs.path &&
> c->lxc_conf->rootfs.mount) {
> r = bdev_init(c->lxc_conf->rootfs.path,
> c->lxc_conf->rootfs.mount, NULL);
> if (r) {
> if (r->ops->destroy(r) < 0) {
> @@ -1857,7 +1865,7 @@ static bool lxcapi_destroy(struct lxc_container *c)
> const char *p1 = lxcapi_get_config_path(c);
> char *path = alloca(strlen(p1) + strlen(c->name) + 2);
> sprintf(path, "%s/%s", p1, c->name);
> - if (am_unpriv)
> + if (am_unpriv(c))
> ret = userns_exec_1(c->lxc_conf, lxc_rmdir_onedev_wrapper,
> path);
> else
> ret = lxc_rmdir_onedev(path);
> @@ -2406,6 +2414,9 @@ static struct lxc_container *lxcapi_clone(struct
> lxc_container *c, const char *n
> if (!c || !c->is_defined(c))
> return NULL;
>
> + if (am_unpriv(c))
> + return NULL;
> +
> if (container_mem_lock(c))
> return NULL;
>
> @@ -2587,6 +2598,9 @@ static int lxcapi_snapshot(struct lxc_container *c,
> const char *commentfile)
> struct lxc_container *c2;
> char snappath[MAXPATHLEN], newname[20];
>
> + if (am_unpriv(c))
> + return -1;
> +
> // /var/lib/lxc -> /var/lib/lxcsnaps \0
> ret = snprintf(snappath, MAXPATHLEN, "%ssnaps/%s", c->config_path,
> c->name);
> if (ret < 0 || ret >= MAXPATHLEN)
> @@ -2802,6 +2816,9 @@ static bool lxcapi_snapshot_restore(struct
> lxc_container *c, const char *snapnam
> if (!c || !c->name || !c->config_path)
> return false;
>
> + if (am_
[lxc-devel] [PATCH] handle unprivileged user calls more gracefully
Return an error if the function is not supposed to be called by an unprivileged
user.
Otherwise those calls fail in the middle of their execution with different
reasons.
Signed-off-by: S.Çağlar Onur
---
src/lxc/lxccontainer.c | 33 -
1 file changed, 28 insertions(+), 5 deletions(-)
diff --git a/src/lxc/lxccontainer.c b/src/lxc/lxccontainer.c
index 0bebdff..8d49e94 100644
--- a/src/lxc/lxccontainer.c
+++ b/src/lxc/lxccontainer.c
@@ -64,6 +64,10 @@
lxc_log_define(lxc_container, lxc);
+static bool am_unpriv(struct lxc_container *c) {
+ return c->lxc_conf && geteuid() != 0 &&
!lxc_list_empty(&c->lxc_conf->id_map);
+}
+
static bool file_exists(const char *f)
{
struct stat statbuf;
@@ -1489,6 +1493,9 @@ static char** lxcapi_get_interfaces(struct lxc_container
*c)
char **interfaces = NULL;
int old_netns = -1, new_netns = -1;
+ if (am_unpriv(c))
+ goto out;
+
if (!enter_to_ns(c, &old_netns, &new_netns))
goto out;
@@ -1538,6 +1545,9 @@ static char** lxcapi_get_ips(struct lxc_container *c,
const char* interface, con
char *address = NULL;
int old_netns = -1, new_netns = -1;
+ if (am_unpriv(c))
+ goto out;
+
if (!enter_to_ns(c, &old_netns, &new_netns))
goto out;
@@ -1818,7 +1828,7 @@ static int lxc_rmdir_onedev_wrapper(void *data)
static bool lxcapi_destroy(struct lxc_container *c)
{
struct bdev *r = NULL;
- bool bret = false, am_unpriv;
+ bool bret = false;
int ret;
if (!c || !lxcapi_is_defined(c))
@@ -1833,14 +1843,12 @@ static bool lxcapi_destroy(struct lxc_container *c)
goto out;
}
- am_unpriv = c->lxc_conf && geteuid() != 0 &&
!lxc_list_empty(&c->lxc_conf->id_map);
-
if (c->lxc_conf && has_snapshots(c)) {
ERROR("container %s has dependent snapshots", c->name);
goto out;
}
- if (!am_unpriv && c->lxc_conf->rootfs.path &&
c->lxc_conf->rootfs.mount) {
+ if (!am_unpriv(c) && c->lxc_conf->rootfs.path &&
c->lxc_conf->rootfs.mount) {
r = bdev_init(c->lxc_conf->rootfs.path,
c->lxc_conf->rootfs.mount, NULL);
if (r) {
if (r->ops->destroy(r) < 0) {
@@ -1857,7 +1865,7 @@ static bool lxcapi_destroy(struct lxc_container *c)
const char *p1 = lxcapi_get_config_path(c);
char *path = alloca(strlen(p1) + strlen(c->name) + 2);
sprintf(path, "%s/%s", p1, c->name);
- if (am_unpriv)
+ if (am_unpriv(c))
ret = userns_exec_1(c->lxc_conf, lxc_rmdir_onedev_wrapper,
path);
else
ret = lxc_rmdir_onedev(path);
@@ -2406,6 +2414,9 @@ static struct lxc_container *lxcapi_clone(struct
lxc_container *c, const char *n
if (!c || !c->is_defined(c))
return NULL;
+ if (am_unpriv(c))
+ return NULL;
+
if (container_mem_lock(c))
return NULL;
@@ -2587,6 +2598,9 @@ static int lxcapi_snapshot(struct lxc_container *c, const
char *commentfile)
struct lxc_container *c2;
char snappath[MAXPATHLEN], newname[20];
+ if (am_unpriv(c))
+ return -1;
+
// /var/lib/lxc -> /var/lib/lxcsnaps \0
ret = snprintf(snappath, MAXPATHLEN, "%ssnaps/%s", c->config_path,
c->name);
if (ret < 0 || ret >= MAXPATHLEN)
@@ -2802,6 +2816,9 @@ static bool lxcapi_snapshot_restore(struct lxc_container
*c, const char *snapnam
if (!c || !c->name || !c->config_path)
return false;
+ if (am_unpriv(c))
+ return false;
+
bdev = bdev_init(c->lxc_conf->rootfs.path, c->lxc_conf->rootfs.mount,
NULL);
if (!bdev) {
ERROR("Failed to find original backing store type");
@@ -2851,6 +2868,9 @@ static bool lxcapi_snapshot_destroy(struct lxc_container
*c, const char *snapnam
if (!c || !c->name || !c->config_path)
return false;
+ if (am_unpriv(c))
+ return false;
+
ret = snprintf(clonelxcpath, MAXPATHLEN, "%ssnaps/%s", c->config_path,
c->name);
if (ret < 0 || ret >= MAXPATHLEN)
goto err;
@@ -2888,6 +2908,9 @@ static bool add_remove_device_node(struct lxc_container
*c, const char *src_path
char *directory_path = NULL;
const char *p;
+ if (am_unpriv(c))
+ goto out;
+
/* make sure container is running */
if (!c->is_running(c)) {
ERROR("container is not running");
--
1.8.3.2
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] Containers do not start with lxc-1.0.0.beta2 on RHEL-6.5
Hello all,
since yesterday I'm testing lxc-1.0.0.beta2 on a RHEL-6.5, but I
failed to get any container to start.
I've set up a RHEL-6.5 test server with the "cgconfig" service enabled
in default configuration. When I try to start a container (with root
privileges), I get:
# lxc-start -n test -d -o lxc-start.log -l DEBUG
lxc-start: command get_cgroup failed to receive response
The container did not start, and lxc-start.log has the following ERRORs:
(leading whitespace trimmed)
lxc-start 1389968577.048 ERRORlxc_cgroup - Could not set clone_children to
1 for cpuset hierarchy in parent cgroup.
lxc-start 1389968577.048 ERRORlxc_cgroup - Device or resource busy -
cgroup_rmdir: failed to delete /cgroup/blkio/
lxc-start 1389968577.048 ERRORlxc_cgroup - Device or resource busy -
cgroup_rmdir: failed to delete /cgroup/net_cls/
lxc-start 1389968577.048 ERRORlxc_cgroup - Device or resource busy -
cgroup_rmdir: failed to delete /cgroup/freezer/
lxc-start 1389968577.048 ERRORlxc_cgroup - Device or resource busy -
cgroup_rmdir: failed to delete /cgroup/devices/
lxc-start 1389968577.048 ERRORlxc_cgroup - Device or resource busy -
cgroup_rmdir: failed to delete /cgroup/memory/
lxc-start 1389968577.048 ERRORlxc_cgroup - Device or resource busy -
cgroup_rmdir: failed to delete /cgroup/cpuacct/
lxc-start 1389968577.049 ERRORlxc_cgroup - Device or resource busy -
cgroup_rmdir: failed to delete /cgroup/cpu/
lxc-start 1389968577.049 ERRORlxc_cgroup - Device or resource busy -
cgroup_rmdir: failed to delete /cgroup/cpuset/
lxc-start 1389968577.049 ERRORlxc_start - failed to create cgroups for
'test'
lxc-start 1389968577.078 ERRORlxc_start - failed to spawn 'test'
lxc-start 1389968577.079 ERRORlxc_commands - command get_cgroup failed to
receive response
The first error comes from cgroup.c:lxc_cgroup_create(). When comparing
this with cgroup.c:set_clone_children() from lxc-0.9.0 I saw that 0.9.0
ignored errors when setting clone_children, and so I patched
cgroup.c:lxc_cgroup_create() to do the same. But the container still did
not start. The errors in lxc-start.log were now:
lxc-start 1389980209.248 ERRORlxc_cgroup - No space left on device - Could
not add pid 21347 to cgroup /lxc/test: internal error
lxc-start 1389980209.270 ERRORlxc_start - failed to spawn 'test'
lxc-start 1389980209.271 ERRORlxc_commands - command get_cgroup failed to
receive response
Using strace(8), I found this:
open("/cgroup/cpuset/lxc/test/tasks", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666)
= 11
write(11, "21347", 5) = -1 ENOSPC (No space left on device)
close(11) = 0
Switching back to lxc-0.9.0, this same container starts just fine.
0.9.0 has its own set of problems when used under RHEL-6.5, but containers
do at least start - and can be shut down again. I had hoped that 1.0.0
would resolve the issues of 0.9.0... (lxc-ps and lxc-netstat don't work)
So, my first question would be: Is RHEL-6.5 (and CentOS 6.5, and others)
a "supported" platform for lxc-1.0.0?
And if so: What should I do to debug this further? Are there already
some patches I could test?
Robert
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] exclude non-existing signals from the loop
On Fri, Jan 17, 2014 at 12:17:55PM -0500, Michael H. Warfield wrote:
> On Fri, 2014-01-17 at 08:24 -0600, Serge Hallyn wrote:
> > Quoting Qiang Huang (h.huangqi...@huawei.com):
> > > On 2014/1/17 5:38, Serge Hallyn wrote:
> > > > Quoting S.Çağlar Onur (cag...@10ur.org):
> > > >> On Thu, Jan 16, 2014 at 4:24 PM, Serge Hallyn
> > > >> wrote:
> > > >>> Quoting S.Çağlar Onur (cag...@10ur.org):
> > > 32 and 33 are not defined and causing sigaction to fail. "kill -l"
> > > shows following
> > > on my system
> > >
> > > 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5)
> > > SIGTRAP
> > > 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10)
> > > SIGUSR1
> > > 11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15)
> > > SIGTERM
> > > 16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20)
> > > SIGTSTP
> > > 21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25)
> > > SIGXFSZ
> > > 26) SIGVTALRM 27) SIGPROF 28) SIGWINCH29) SIGIO 30)
> > > SIGPWR
> > > 31) SIGSYS 34) SIGRTMIN35) SIGRTMIN+1 36) SIGRTMIN+2 37)
> > > SIGRTMIN+3
> > > 38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42)
> > > SIGRTMIN+8
> > > 43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47)
> > > SIGRTMIN+13
> > > 48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52)
> > > SIGRTMAX-12
> > > 53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57)
> > > SIGRTMAX-7
> > > 58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62)
> > > SIGRTMAX-2
> > > 63) SIGRTMAX-1 64) SIGRTMAX
> > >
> > > Signed-off-by: S.Çağlar Onur
> > > >>>
> > > >>> Odd... on my system NSIG is 32, so these should never hit (since it
> > > >>> is
> > > >>> in a while i > > >>
> > > >> Printing NSIG via ERROR shows that its 64 on my system.
> > > >
> > > > So a header file is #defining NSIG, which is already defined to 32
> > > > in kernel headers, to _NSIG, which is 64.
> > > >
> > > > Looking around the current state of kernel headers, i wonder whether
> > > > we should imply use min(SIGRTMIN, NSIG).
> > >
> > > My box is x86_64, and I got the same result as S.Çağlar.
> > >
> > > People may use signal number bigger than SIGRTMIN, so min(SIGRTMIN, NSIG)
> > > would miss them. Isn't that cause any problems?
> > >
> > > Maybe we should just bypass there non-existent signals.
> >
> > If we could know on any system which signals to bypass that'd be
> > fine, but AFAICS we can't.
>
> > It sounds to me like we should simply ignore failure at sigaction like
> > we used to :) Something like below. Is that what you meant?
>
> That would make the most sense to me.
>
> What would be the downside to ignoring the failure? Are there any error
> condition which we should not ignore?
>
> The man page indicates that errno has two defined values on failure.
> Either EINVAL, meaning an invalid signal was specified and we SHOULD
> ignore it, or EFAULT indicating something wrong with the pointers passed
> to it, which indicates something seriously wrong in the code. That
> doesn't mean there might not be others that they didn't think to
> list... :-P
So maybe show the INFO on EINVAL and hard fail on anything else?
>
> > From 87319b691c8f65c7d61ee01e64707d0b59d11caa Mon Sep 17 00:00:00 2001
> > From: Serge Hallyn
> > Date: Fri, 17 Jan 2014 08:23:18 -0600
> > Subject: [PATCH 1/1] lxc_init: don't fail on bad signals
> >
> > Signed-off-by: Serge Hallyn
> > ---
> > src/lxc/lxc_init.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/src/lxc/lxc_init.c b/src/lxc/lxc_init.c
> > index a59dd9c..b86edf8 100644
> > --- a/src/lxc/lxc_init.c
> > +++ b/src/lxc/lxc_init.c
> > @@ -159,8 +159,7 @@ int main(int argc, char *argv[])
> > act.sa_flags = 0;
> > act.sa_handler = interrupt_handler;
> > if (sigaction(i, &act, NULL)) {
> > - SYSERROR("failed to sigaction");
> > - exit(EXIT_FAILURE);
> > + INFO ("failed to sigaction (%d)", i);
> > }
> > }
> >
> > --
> > 1.8.5.2
> >
> > ___
> > lxc-devel mailing list
> > lxc-devel@lists.linuxcontainers.org
> > http://lists.linuxcontainers.org/listinfo/lxc-devel
> >
>
> --
> Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com
>/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
>NIC whois: MHW9 | An optimist believes we live in the best of all
> PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it!
>
> ___
> lxc-devel mailing list
> lxc-devel@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] exclude non-existing signals from the loop
On Fri, 2014-01-17 at 08:24 -0600, Serge Hallyn wrote:
> Quoting Qiang Huang (h.huangqi...@huawei.com):
> > On 2014/1/17 5:38, Serge Hallyn wrote:
> > > Quoting S.Çağlar Onur (cag...@10ur.org):
> > >> On Thu, Jan 16, 2014 at 4:24 PM, Serge Hallyn
> > >> wrote:
> > >>> Quoting S.Çağlar Onur (cag...@10ur.org):
> > 32 and 33 are not defined and causing sigaction to fail. "kill -l"
> > shows following
> > on my system
> >
> > 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5)
> > SIGTRAP
> > 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10)
> > SIGUSR1
> > 11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15)
> > SIGTERM
> > 16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20)
> > SIGTSTP
> > 21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25)
> > SIGXFSZ
> > 26) SIGVTALRM 27) SIGPROF 28) SIGWINCH29) SIGIO 30)
> > SIGPWR
> > 31) SIGSYS 34) SIGRTMIN35) SIGRTMIN+1 36) SIGRTMIN+2 37)
> > SIGRTMIN+3
> > 38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42)
> > SIGRTMIN+8
> > 43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47)
> > SIGRTMIN+13
> > 48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52)
> > SIGRTMAX-12
> > 53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57)
> > SIGRTMAX-7
> > 58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62)
> > SIGRTMAX-2
> > 63) SIGRTMAX-1 64) SIGRTMAX
> >
> > Signed-off-by: S.Çağlar Onur
> > >>>
> > >>> Odd... on my system NSIG is 32, so these should never hit (since it is
> > >>> in a while i > >>
> > >> Printing NSIG via ERROR shows that its 64 on my system.
> > >
> > > So a header file is #defining NSIG, which is already defined to 32
> > > in kernel headers, to _NSIG, which is 64.
> > >
> > > Looking around the current state of kernel headers, i wonder whether
> > > we should imply use min(SIGRTMIN, NSIG).
> >
> > My box is x86_64, and I got the same result as S.Çağlar.
> >
> > People may use signal number bigger than SIGRTMIN, so min(SIGRTMIN, NSIG)
> > would miss them. Isn't that cause any problems?
> >
> > Maybe we should just bypass there non-existent signals.
>
> If we could know on any system which signals to bypass that'd be
> fine, but AFAICS we can't.
> It sounds to me like we should simply ignore failure at sigaction like
> we used to :) Something like below. Is that what you meant?
That would make the most sense to me.
What would be the downside to ignoring the failure? Are there any error
condition which we should not ignore?
The man page indicates that errno has two defined values on failure.
Either EINVAL, meaning an invalid signal was specified and we SHOULD
ignore it, or EFAULT indicating something wrong with the pointers passed
to it, which indicates something seriously wrong in the code. That
doesn't mean there might not be others that they didn't think to
list... :-P
> From 87319b691c8f65c7d61ee01e64707d0b59d11caa Mon Sep 17 00:00:00 2001
> From: Serge Hallyn
> Date: Fri, 17 Jan 2014 08:23:18 -0600
> Subject: [PATCH 1/1] lxc_init: don't fail on bad signals
>
> Signed-off-by: Serge Hallyn
> ---
> src/lxc/lxc_init.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/src/lxc/lxc_init.c b/src/lxc/lxc_init.c
> index a59dd9c..b86edf8 100644
> --- a/src/lxc/lxc_init.c
> +++ b/src/lxc/lxc_init.c
> @@ -159,8 +159,7 @@ int main(int argc, char *argv[])
> act.sa_flags = 0;
> act.sa_handler = interrupt_handler;
> if (sigaction(i, &act, NULL)) {
> - SYSERROR("failed to sigaction");
> - exit(EXIT_FAILURE);
> + INFO ("failed to sigaction (%d)", i);
> }
> }
>
> --
> 1.8.5.2
>
> ___
> lxc-devel mailing list
> lxc-devel@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-devel
>
--
Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it!
signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] exclude non-existing signals from the loop
On Fri, Jan 17, 2014 at 9:24 AM, Serge Hallyn wrote:
> Quoting Qiang Huang (h.huangqi...@huawei.com):
>> On 2014/1/17 5:38, Serge Hallyn wrote:
>> > Quoting S.Çağlar Onur (cag...@10ur.org):
>> >> On Thu, Jan 16, 2014 at 4:24 PM, Serge Hallyn
>> >> wrote:
>> >>> Quoting S.Çağlar Onur (cag...@10ur.org):
>> 32 and 33 are not defined and causing sigaction to fail. "kill -l"
>> shows following
>> on my system
>>
>> 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5)
>> SIGTRAP
>> 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10)
>> SIGUSR1
>> 11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15)
>> SIGTERM
>> 16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20)
>> SIGTSTP
>> 21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25)
>> SIGXFSZ
>> 26) SIGVTALRM 27) SIGPROF 28) SIGWINCH29) SIGIO 30)
>> SIGPWR
>> 31) SIGSYS 34) SIGRTMIN35) SIGRTMIN+1 36) SIGRTMIN+2 37)
>> SIGRTMIN+3
>> 38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42)
>> SIGRTMIN+8
>> 43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47)
>> SIGRTMIN+13
>> 48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52)
>> SIGRTMAX-12
>> 53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57)
>> SIGRTMAX-7
>> 58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62)
>> SIGRTMAX-2
>> 63) SIGRTMAX-1 64) SIGRTMAX
>>
>> Signed-off-by: S.Çağlar Onur
>> >>>
>> >>> Odd... on my system NSIG is 32, so these should never hit (since it is
>> >>> in a while i> >>
>> >> Printing NSIG via ERROR shows that its 64 on my system.
>> >
>> > So a header file is #defining NSIG, which is already defined to 32
>> > in kernel headers, to _NSIG, which is 64.
>> >
>> > Looking around the current state of kernel headers, i wonder whether
>> > we should imply use min(SIGRTMIN, NSIG).
>>
>> My box is x86_64, and I got the same result as S.Çağlar.
>>
>> People may use signal number bigger than SIGRTMIN, so min(SIGRTMIN, NSIG)
>> would miss them. Isn't that cause any problems?
>>
>> Maybe we should just bypass there non-existent signals.
>
> If we could know on any system which signals to bypass that'd be
> fine, but AFAICS we can't.
>
> It sounds to me like we should simply ignore failure at sigaction like
> we used to :) Something like below. Is that what you meant?
>
> From 87319b691c8f65c7d61ee01e64707d0b59d11caa Mon Sep 17 00:00:00 2001
> From: Serge Hallyn
> Date: Fri, 17 Jan 2014 08:23:18 -0600
> Subject: [PATCH 1/1] lxc_init: don't fail on bad signals
>
> Signed-off-by: Serge Hallyn
> ---
> src/lxc/lxc_init.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/src/lxc/lxc_init.c b/src/lxc/lxc_init.c
> index a59dd9c..b86edf8 100644
> --- a/src/lxc/lxc_init.c
> +++ b/src/lxc/lxc_init.c
> @@ -159,8 +159,7 @@ int main(int argc, char *argv[])
> act.sa_flags = 0;
> act.sa_handler = interrupt_handler;
> if (sigaction(i, &act, NULL)) {
> - SYSERROR("failed to sigaction");
> - exit(EXIT_FAILURE);
> + INFO ("failed to sigaction (%d)", i);
> }
> }
>
> --
> 1.8.5.2
Yep make sense and much better than hardcoding 32 and 33 in the loop as I did :)
> ___
> lxc-devel mailing list
> lxc-devel@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-devel
--
S.Çağlar Onur
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [lxc/lxc] 348cb2: doc: Update Japanese lxc-ls(1) for -f and -F optio...
Branch: refs/heads/master Home: https://github.com/lxc/lxc Commit: 348cb247dbb92940b5684c12b43579bccba85dab https://github.com/lxc/lxc/commit/348cb247dbb92940b5684c12b43579bccba85dab Author: KATOH Yasufumi Date: 2014-01-17 (Fri, 17 Jan 2014) Changed paths: M doc/ja/lxc-ls.sgml.in Log Message: --- doc: Update Japanese lxc-ls(1) for -f and -F option Update for commit c5afb6e455d9ec00af9f3399836152eaf9d0a4f5 Signed-off-by: KATOH Yasufumi Acked-by: Stéphane Graber ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] doc: Update Japanese lxc-ls(1) for -f and -F option
On Fri, Jan 17, 2014 at 05:12:14PM +0900, KATOH Yasufumi wrote: > Update for commit c5afb6e455d9ec00af9f3399836152eaf9d0a4f5 > > Signed-off-by: KATOH Yasufumi Acked-by: Stéphane Graber > --- > doc/ja/lxc-ls.sgml.in | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/doc/ja/lxc-ls.sgml.in b/doc/ja/lxc-ls.sgml.in > index 4bab189..3ca1e78 100644 > --- a/doc/ja/lxc-ls.sgml.in > +++ b/doc/ja/lxc-ls.sgml.in > @@ -59,8 +59,8 @@ by KATOH Yasufumi >--frozen >--running >--stopped > - --fancy > - --fancy-format > + -f > + -F format >--nesting >filter > > @@ -152,7 +152,7 @@ by KATOH Yasufumi > > > > - --fancy > + -f, --fancy > > > > @@ -166,7 +166,7 @@ by KATOH Yasufumi > > > > - --fancy-format > + -F, --fancy-format > format > > > > -- > 1.8.4.4 > > ___ > lxc-devel mailing list > lxc-devel@lists.linuxcontainers.org > http://lists.linuxcontainers.org/listinfo/lxc-devel -- Stéphane Graber Ubuntu developer http://www.ubuntu.com signature.asc Description: Digital signature ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] exclude non-existing signals from the loop
On 2014年01月17日 22:24, Serge Hallyn wrote:
> If we could know on any system which signals to bypass that'd be
> fine, but AFAICS we can't.
>
> It sounds to me like we should simply ignore failure at sigaction like
> we used to :) Something like below. Is that what you meant?
>
> From 87319b691c8f65c7d61ee01e64707d0b59d11caa Mon Sep 17 00:00:00 2001
> From: Serge Hallyn
> Date: Fri, 17 Jan 2014 08:23:18 -0600
> Subject: [PATCH 1/1] lxc_init: don't fail on bad signals
>
> Signed-off-by: Serge Hallyn
> ---
> src/lxc/lxc_init.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/src/lxc/lxc_init.c b/src/lxc/lxc_init.c
> index a59dd9c..b86edf8 100644
> --- a/src/lxc/lxc_init.c
> +++ b/src/lxc/lxc_init.c
> @@ -159,8 +159,7 @@ int main(int argc, char *argv[])
> act.sa_flags = 0;
> act.sa_handler = interrupt_handler;
> if (sigaction(i, &act, NULL)) {
> - SYSERROR("failed to sigaction");
> - exit(EXIT_FAILURE);
> + INFO ("failed to sigaction (%d)", i);
> }
> }
>
>
Yeah, I can live with that :)
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] exclude non-existing signals from the loop
Quoting Qiang Huang (h.huangqi...@huawei.com):
> On 2014/1/17 5:38, Serge Hallyn wrote:
> > Quoting S.Çağlar Onur (cag...@10ur.org):
> >> On Thu, Jan 16, 2014 at 4:24 PM, Serge Hallyn
> >> wrote:
> >>> Quoting S.Çağlar Onur (cag...@10ur.org):
> 32 and 33 are not defined and causing sigaction to fail. "kill -l" shows
> following
> on my system
>
> 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5)
> SIGTRAP
> 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10)
> SIGUSR1
> 11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15)
> SIGTERM
> 16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20)
> SIGTSTP
> 21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25)
> SIGXFSZ
> 26) SIGVTALRM 27) SIGPROF 28) SIGWINCH29) SIGIO 30)
> SIGPWR
> 31) SIGSYS 34) SIGRTMIN35) SIGRTMIN+1 36) SIGRTMIN+2 37)
> SIGRTMIN+3
> 38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42)
> SIGRTMIN+8
> 43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47)
> SIGRTMIN+13
> 48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52)
> SIGRTMAX-12
> 53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57)
> SIGRTMAX-7
> 58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62)
> SIGRTMAX-2
> 63) SIGRTMAX-1 64) SIGRTMAX
>
> Signed-off-by: S.Çağlar Onur
> >>>
> >>> Odd... on my system NSIG is 32, so these should never hit (since it is
> >>> in a while i >>
> >> Printing NSIG via ERROR shows that its 64 on my system.
> >
> > So a header file is #defining NSIG, which is already defined to 32
> > in kernel headers, to _NSIG, which is 64.
> >
> > Looking around the current state of kernel headers, i wonder whether
> > we should imply use min(SIGRTMIN, NSIG).
>
> My box is x86_64, and I got the same result as S.Çağlar.
>
> People may use signal number bigger than SIGRTMIN, so min(SIGRTMIN, NSIG)
> would miss them. Isn't that cause any problems?
>
> Maybe we should just bypass there non-existent signals.
If we could know on any system which signals to bypass that'd be
fine, but AFAICS we can't.
It sounds to me like we should simply ignore failure at sigaction like
we used to :) Something like below. Is that what you meant?
From 87319b691c8f65c7d61ee01e64707d0b59d11caa Mon Sep 17 00:00:00 2001
From: Serge Hallyn
Date: Fri, 17 Jan 2014 08:23:18 -0600
Subject: [PATCH 1/1] lxc_init: don't fail on bad signals
Signed-off-by: Serge Hallyn
---
src/lxc/lxc_init.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/lxc/lxc_init.c b/src/lxc/lxc_init.c
index a59dd9c..b86edf8 100644
--- a/src/lxc/lxc_init.c
+++ b/src/lxc/lxc_init.c
@@ -159,8 +159,7 @@ int main(int argc, char *argv[])
act.sa_flags = 0;
act.sa_handler = interrupt_handler;
if (sigaction(i, &act, NULL)) {
- SYSERROR("failed to sigaction");
- exit(EXIT_FAILURE);
+ INFO ("failed to sigaction (%d)", i);
}
}
--
1.8.5.2
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [PATCH] doc: Update Japanese lxc-ls(1) for -f and -F option
Update for commit c5afb6e455d9ec00af9f3399836152eaf9d0a4f5 Signed-off-by: KATOH Yasufumi --- doc/ja/lxc-ls.sgml.in | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/ja/lxc-ls.sgml.in b/doc/ja/lxc-ls.sgml.in index 4bab189..3ca1e78 100644 --- a/doc/ja/lxc-ls.sgml.in +++ b/doc/ja/lxc-ls.sgml.in @@ -59,8 +59,8 @@ by KATOH Yasufumi --frozen --running --stopped - --fancy - --fancy-format + -f + -F format --nesting filter @@ -152,7 +152,7 @@ by KATOH Yasufumi - --fancy + -f, --fancy @@ -166,7 +166,7 @@ by KATOH Yasufumi - --fancy-format + -F, --fancy-format format -- 1.8.4.4 ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
