[lxc-devel] [PATCH] lxc-alpine: allow /dev/full
The template creates /dev/full for the container but needs also give permission to access it. Signed-off-by: Natanael Copa nc...@alpinelinux.org --- templates/lxc-alpine.in | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/templates/lxc-alpine.in b/templates/lxc-alpine.in index 5fdf36f..8600a34 100644 --- a/templates/lxc-alpine.in +++ b/templates/lxc-alpine.in @@ -197,9 +197,10 @@ lxc.cap.drop = sys_module mac_admin mac_override sys_time # devices lxc.cgroup.devices.deny = a -# /dev/null and zero +# /dev/null, zero and full lxc.cgroup.devices.allow = c 1:3 rwm lxc.cgroup.devices.allow = c 1:5 rwm +lxc.cgroup.devices.allow = c 1:7 rwm # consoles lxc.cgroup.devices.allow = c 5:1 rwm lxc.cgroup.devices.allow = c 5:0 rwm -- 1.8.4.1 -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] lxc-alpine: allow /dev/full
Quoting Natanael Copa (nc...@alpinelinux.org): The template creates /dev/full for the container but needs also give permission to access it. Acked-by: Serge E. Hallyn serge.hal...@ubuntu.com Signed-off-by: Natanael Copa nc...@alpinelinux.org --- templates/lxc-alpine.in | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/templates/lxc-alpine.in b/templates/lxc-alpine.in index 5fdf36f..8600a34 100644 --- a/templates/lxc-alpine.in +++ b/templates/lxc-alpine.in @@ -197,9 +197,10 @@ lxc.cap.drop = sys_module mac_admin mac_override sys_time # devices lxc.cgroup.devices.deny = a -# /dev/null and zero +# /dev/null, zero and full lxc.cgroup.devices.allow = c 1:3 rwm lxc.cgroup.devices.allow = c 1:5 rwm +lxc.cgroup.devices.allow = c 1:7 rwm # consoles lxc.cgroup.devices.allow = c 5:1 rwm lxc.cgroup.devices.allow = c 5:0 rwm -- 1.8.4.1 -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [lxc/lxc] 6bd3f9: lxc-alpine: allow /dev/full
Branch: refs/heads/master Home: https://github.com/lxc/lxc Commit: 6bd3f98c469f311f6afbffbb3586efddae3c4eb4 https://github.com/lxc/lxc/commit/6bd3f98c469f311f6afbffbb3586efddae3c4eb4 Author: Natanael Copa nc...@alpinelinux.org Date: 2013-10-22 (Tue, 22 Oct 2013) Changed paths: M templates/lxc-alpine.in Log Message: --- lxc-alpine: allow /dev/full The template creates /dev/full for the container but needs also give permission to access it. Signed-off-by: Natanael Copa nc...@alpinelinux.org Signed-off-by: Serge Hallyn serge.hal...@ubuntu.com -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] umount $rootfs/lib on errors as well otherwise system ends up with stalled mounts
Quoting S.Çağlar Onur (cag...@10ur.org): Hi Serge, Then there must be something else going on cause without this patch I find myself in the situation that I described earlier in this email [1] [1] http://sourceforge.net/mailarchive/message.php?msg_id=31539485 Oh - yeah - but it doesn't show up in /proc/self/mounts does it? What I think we actually need is: From db4e0250bb547f84032584a79dcd84f8ce361ef1 Mon Sep 17 00:00:00 2001 From: Serge Hallyn serge.hal...@ubuntu.com Date: Tue, 22 Oct 2013 11:34:46 -0500 Subject: [PATCH 1/1] lxc-busybox: don't copy temp mounts into mtab Signed-off-by: Serge Hallyn serge.hal...@ubuntu.com --- templates/lxc-busybox.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/templates/lxc-busybox.in b/templates/lxc-busybox.in index cbdaaf3..29dc36d 100644 --- a/templates/lxc-busybox.in +++ b/templates/lxc-busybox.in @@ -196,7 +196,7 @@ configure_busybox() cat EOF $CHPASSWD_FILE echo setting root password to \root\ -mount --bind /lib $rootfs/lib +mount -n --bind /lib $rootfs/lib if [ \$? -ne 0 ]; then echo Failed bind-mounting /lib at $rootfs/lib exit 1 -- 1.8.1.2 -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] Use actual length of socket's name for abstract sockets
Quoting S.Çağlar Onur (cag...@10ur.org): Hi, On Mon, Oct 21, 2013 at 8:30 PM, Serge Hallyn serge.hal...@ubuntu.comwrote: Quoting S.Çağlar Onur (cag...@10ur.org): The addrlen parameter should be the actual length of socket's name for abstract sockets. Otherwise socket gets padded with NULLs. cat /proc/net/unix | grep lxc [...] : 0003 0001 03 226548 @lxc/ad055575fe28ddd5//var/lib/lxc^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ [...] with this patch; cat /proc/net/unix | grep lxc [...] : 0002 0001 0001 01 109563 @lxc/ad055575fe28ddd5//var/lib/lxc [...] Yeah I've noticed that too :) However, you can't just take the length of the passed-in string, you need to make sure it's no larger than sizeof(addr.sun_path)-1. Is that being guaranteed somewhere else that I'm glossing over? Hmm I think current code path also lacks that check. As long as I see we only control the length in lxc_af_unix_open for non-abstract case. I'll add the checks and iterate one more time sometime this week. Thanks! -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] Eliminate duplicate entries from list_active_containers
Quoting S.Çağlar Onur (cag...@10ur.org): Hi, On Mon, Oct 21, 2013 at 8:22 PM, Serge Hallyn serge.hal...@ubuntu.comwrote: Quoting S.Çağlar Onur (cag...@10ur.org): list_active_containers parses /proc/net/unix which can contain multiple entries for the same container; : 0002 0001 0001 01 273672 @/var/lib/lxc/6/command : 0002 0001 0001 01 274395 @/var/lib/lxc/5/command : 0002 0001 0001 01 273890 @/var/lib/lxc/4/command : 0002 0001 0001 01 273141 @/var/lib/lxc/3/command : 0002 0001 0001 01 273915 @/var/lib/lxc/2/command : 0002 0001 0001 01 273683 @/var/lib/lxc/1/command : 0002 0001 0001 01 273074 @/var/lib/lxc/0/command : 0002 0001 0001 01 273931 @/var/lib/lxc/9/command : 0002 0001 0001 01 273110 @/var/lib/lxc/8/command : 0002 0001 0001 01 273390 @/var/lib/lxc/7/command : 0003 0001 03 275903 @/var/lib/lxc/8/command : 0003 0001 03 276043 @/var/lib/lxc/1/command : 0003 0001 03 273301 @/var/lib/lxc/0/command : 0003 0001 03 275650 @/var/lib/lxc/4/command On this system list_active_containers returns 14 containers while only 10 containers are running. Following patch; * Introduces array_contains function to do a binary search on given array, * Starts to sort arrays inside the add_to_clist and add_to_names functions, * Consumes array_contains in list_active_containers to eliminate duplicates, * Replaces the linear search code in lxcapi_get_interfaces with the new function. Thanks - that patch on the whole is good, except that you move the adding to *names in list_active_containers() to after the attempt to load the container. Not loading the container if a container list is not passed in is deliberately done to avoid a potentially large amount of work. (The very low potential for differing results when passing in *cret and not is deemed worthwhile) OK, I was just trying to make sure both cases return same result :) I'll iterate one more time with that change. Thanks - everything else looked good. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] umount $rootfs/lib on errors as well otherwise system ends up with stalled mounts
On Tue, Oct 22, 2013 at 11:41:31AM -0500, Serge Hallyn wrote: Quoting S.Çağlar Onur (cag...@10ur.org): Hi Serge, Then there must be something else going on cause without this patch I find myself in the situation that I described earlier in this email [1] [1] http://sourceforge.net/mailarchive/message.php?msg_id=31539485 Oh - yeah - but it doesn't show up in /proc/self/mounts does it? What I think we actually need is: From db4e0250bb547f84032584a79dcd84f8ce361ef1 Mon Sep 17 00:00:00 2001 From: Serge Hallyn serge.hal...@ubuntu.com Date: Tue, 22 Oct 2013 11:34:46 -0500 Subject: [PATCH 1/1] lxc-busybox: don't copy temp mounts into mtab Signed-off-by: Serge Hallyn serge.hal...@ubuntu.com Yes, we should never write to mtab when in a separate mount namespace. Acked-by: Stéphane Graber stgra...@ubuntu.com --- templates/lxc-busybox.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/templates/lxc-busybox.in b/templates/lxc-busybox.in index cbdaaf3..29dc36d 100644 --- a/templates/lxc-busybox.in +++ b/templates/lxc-busybox.in @@ -196,7 +196,7 @@ configure_busybox() cat EOF $CHPASSWD_FILE echo setting root password to \root\ -mount --bind /lib $rootfs/lib +mount -n --bind /lib $rootfs/lib if [ \$? -ne 0 ]; then echo Failed bind-mounting /lib at $rootfs/lib exit 1 -- 1.8.1.2 -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel -- Stéphane Graber Ubuntu developer http://www.ubuntu.com signature.asc Description: Digital signature -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [lxc/lxc] 7a409f: lxc-busybox: don't copy temp mounts into mtab
Branch: refs/heads/master Home: https://github.com/lxc/lxc Commit: 7a409fd5167ecdcbf33a64f1cf9202dc051f0dcf https://github.com/lxc/lxc/commit/7a409fd5167ecdcbf33a64f1cf9202dc051f0dcf Author: Serge Hallyn serge.hal...@ubuntu.com Date: 2013-10-22 (Tue, 22 Oct 2013) Changed paths: M templates/lxc-busybox.in Log Message: --- lxc-busybox: don't copy temp mounts into mtab Signed-off-by: Serge Hallyn serge.hal...@ubuntu.com Acked-by: Stéphane Graber stgra...@ubuntu.com -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] Kernel bug? Setuid apps and user namespaces
I've been playing with User Namespaces somewhat extensively and I think I've
come across a bug in the handling of /proc/$PID/ entries.
This is my example case on a 3.10.x kernel:
-- /var/lib/lxc/test1/config
lxc.rootfs = /lxc/c1
lxc.id_map = u 0 100 10
lxc.id_map = g 0 100 10
lxc.network.type = none
lxc.tty = 6
== END
On one console login as a non-root user and run su, as an example of a
setuid root application. On another console login as root and examine
/proc/$(pidof su). You'll find all the files are owned by the nobody user
and inaccessible. The reason is on the host you'll find these files are owned
by root, uid 0, which is odd because in the container they should be uid
100 from the mappings.
I tracked down the cause to kernel source file /fs/proc/base.c function
pid_revalidate which contains static references to GLOBAL_ROOT_UID and
GLOBAL_ROOT_GID which are always UID 0 on the host. This little patch, which
might not be correct in terms of kernel standards, appears to mostly solve the
issue. It doesn't affect all entries in /proc/$PID but gets the majority of
them.
Thoughts or opinions?
--- linux-3.10-clean/fs/proc/base.c 2013-06-30 18:13:29.0 -0400
+++ linux-3.10-patched/fs/proc/base.c 2013-10-22 13:28:22.561262197 -0400
@@ -1632,17 +1632,17 @@
task = get_proc_task(inode);
if (task) {
+ rcu_read_lock();
+ cred = __task_cred(task);
if ((inode-i_mode == (S_IFDIR|S_IRUGO|S_IXUGO)) ||
task_dumpable(task)) {
- rcu_read_lock();
- cred = __task_cred(task);
inode-i_uid = cred-euid;
inode-i_gid = cred-egid;
- rcu_read_unlock();
} else {
- inode-i_uid = GLOBAL_ROOT_UID;
- inode-i_gid = GLOBAL_ROOT_GID;
+ inode-i_uid = cred ? make_kuid(cred-user_ns, 0) :
GLOBAL_ROOT_UID;
+ inode-i_gid = cred ? make_kgid(cred-user_ns, 0) :
GLOBAL_ROOT_GID;
}
+ rcu_read_unlock();
inode-i_mode = ~(S_ISUID | S_ISGID);
security_task_to_inode(task, inode);
put_task_struct(task);
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] Kernel bug? Setuid apps and user namespaces
Quoting Sean Pajot (sean.pa...@execulink.com):
I've been playing with User Namespaces somewhat extensively and I think I've
come across a bug in the handling of /proc/$PID/ entries.
This is my example case on a 3.10.x kernel:
-- /var/lib/lxc/test1/config
lxc.rootfs = /lxc/c1
lxc.id_map = u 0 100 10
lxc.id_map = g 0 100 10
lxc.network.type = none
lxc.tty = 6
== END
On one console login as a non-root user and run su, as an example of a
setuid root application. On another console login as root and examine
/proc/$(pidof su). You'll find all the files are owned by the nobody user
and inaccessible. The reason is on the host you'll find these files are owned
by root, uid 0, which is odd because in the container they should be uid
100 from the mappings.
I tracked down the cause to kernel source file /fs/proc/base.c function
pid_revalidate which contains static references to GLOBAL_ROOT_UID and
GLOBAL_ROOT_GID which are always UID 0 on the host. This little patch, which
might not be correct in terms of kernel standards, appears to mostly solve the
issue. It doesn't affect all entries in /proc/$PID but gets the majority of
them.
Thoughts or opinions?
Awesome - I've seen this bug and so far not had time to dig.
The patch offhand looks good to me. Do you mind sending it to
lkml?
Acked-by: Serge E. Hallyn serge.hal...@ubuntu.com
--- linux-3.10-clean/fs/proc/base.c 2013-06-30 18:13:29.0 -0400
+++ linux-3.10-patched/fs/proc/base.c 2013-10-22 13:28:22.561262197 -0400
@@ -1632,17 +1632,17 @@
task = get_proc_task(inode);
if (task) {
+ rcu_read_lock();
+ cred = __task_cred(task);
if ((inode-i_mode == (S_IFDIR|S_IRUGO|S_IXUGO)) ||
task_dumpable(task)) {
- rcu_read_lock();
- cred = __task_cred(task);
inode-i_uid = cred-euid;
inode-i_gid = cred-egid;
- rcu_read_unlock();
} else {
- inode-i_uid = GLOBAL_ROOT_UID;
- inode-i_gid = GLOBAL_ROOT_GID;
+ inode-i_uid = cred ? make_kuid(cred-user_ns, 0) :
GLOBAL_ROOT_UID;
+ inode-i_gid = cred ? make_kgid(cred-user_ns, 0) :
GLOBAL_ROOT_GID;
}
+ rcu_read_unlock();
inode-i_mode = ~(S_ISUID | S_ISGID);
security_task_to_inode(task, inode);
put_task_struct(task);
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] Kernel bug? Setuid apps and user namespaces
Serge Hallyn serge.hal...@ubuntu.com writes:
Quoting Sean Pajot (sean.pa...@execulink.com):
I've been playing with User Namespaces somewhat extensively and I think I've
come across a bug in the handling of /proc/$PID/ entries.
This is my example case on a 3.10.x kernel:
-- /var/lib/lxc/test1/config
lxc.rootfs = /lxc/c1
lxc.id_map = u 0 100 10
lxc.id_map = g 0 100 10
lxc.network.type = none
lxc.tty = 6
== END
On one console login as a non-root user and run su, as an example of a
setuid root application. On another console login as root and examine
/proc/$(pidof su). You'll find all the files are owned by the nobody user
and inaccessible. The reason is on the host you'll find these files are owned
by root, uid 0, which is odd because in the container they should be uid
100 from the mappings.
I tracked down the cause to kernel source file /fs/proc/base.c function
pid_revalidate which contains static references to GLOBAL_ROOT_UID and
GLOBAL_ROOT_GID which are always UID 0 on the host. This little patch, which
might not be correct in terms of kernel standards, appears to mostly solve
the
issue. It doesn't affect all entries in /proc/$PID but gets the majority of
them.
Thoughts or opinions?
Awesome - I've seen this bug and so far not had time to dig.
The patch offhand looks good to me. Do you mind sending it to
lkml?
Acked-by: Serge E. Hallyn serge.hal...@ubuntu.com
It is definitely worth looking at. I punted on this when I did the
initial round of conversions. Tasks that we don't consider dumpable are
weird.
At first glance this fine. However __task_cred does not return NULL so
handling that case is nonsense and confusing.
Eric
--- linux-3.10-clean/fs/proc/base.c 2013-06-30 18:13:29.0 -0400
+++ linux-3.10-patched/fs/proc/base.c2013-10-22 13:28:22.561262197
-0400
@@ -1632,17 +1632,17 @@
task = get_proc_task(inode);
if (task) {
+rcu_read_lock();
+cred = __task_cred(task);
if ((inode-i_mode == (S_IFDIR|S_IRUGO|S_IXUGO)) ||
task_dumpable(task)) {
-rcu_read_lock();
-cred = __task_cred(task);
inode-i_uid = cred-euid;
inode-i_gid = cred-egid;
-rcu_read_unlock();
} else {
-inode-i_uid = GLOBAL_ROOT_UID;
-inode-i_gid = GLOBAL_ROOT_GID;
+inode-i_uid = cred ? make_kuid(cred-user_ns, 0) :
GLOBAL_ROOT_UID;
+inode-i_gid = cred ? make_kgid(cred-user_ns, 0) :
GLOBAL_ROOT_GID;
}
+rcu_read_unlock();
inode-i_mode = ~(S_ISUID | S_ISGID);
security_task_to_inode(task, inode);
put_task_struct(task);
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [PATCH] install lua module 0644 instead of 0755
Fixes rpmlint error script-without-shebang. Checked other lua modules and none are installed with execute permission. Signed-off-by: Dwight Engen dwight.en...@oracle.com --- src/lua-lxc/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/lua-lxc/Makefile.am b/src/lua-lxc/Makefile.am index 11eabfd..7bbaf61 100644 --- a/src/lua-lxc/Makefile.am +++ b/src/lua-lxc/Makefile.am @@ -3,7 +3,7 @@ if ENABLE_LUA luadir=$(LUA_INSTALL_LMOD) sodir=$(LUA_INSTALL_CMOD)/lxc -lua_SCRIPTS=lxc.lua +lua_DATA=lxc.lua so_PROGRAMS = core.so -- 1.8.3.1 -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [PATCH] update rpm .spec file
The following changes were made to fix rpmlint warnings/errors
- use %global instead of %define
http://fedoraproject.org/wiki/PackagingDrafts/global_preferred_over_define
- change Summary to match .deb
- update License
- do not mention the libcap dependency explicitly, rpm will fill it in
- fix Summary, Description for libs and devel packages
- pass -q to %setup
- add %post for libs to run ldconfig
- explicitly name lxc man paths so pkg doesn't own /usr/share/man
- mark /etc/lxc/default.conf as a config file
In addition, while I was here:
- split lua bits into seperate lxc-lua package
- change Description to match .deb
- remove Version in changelog entries to follow
http://fedoraproject.org/wiki/Packaging:Guidelines#Changelogs
Signed-off-by: Dwight Engen dwight.en...@oracle.com
---
lxc.spec.in | 109 +++-
1 file changed, 63 insertions(+), 46 deletions(-)
diff --git a/lxc.spec.in b/lxc.spec.in
index a0f2c1a..f4bcd8c 100644
--- a/lxc.spec.in
+++ b/lxc.spec.in
@@ -20,59 +20,62 @@
# License along with this library; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+%global with_python %{?_with_python: 1} %{?!_with_python: 0}
+%global with_lua %{?_with_lua: 1} %{?!_with_lua: 0}
+
Name: @PACKAGE@
Version: @VERSION@
Release: 1%{?dist}
URL: http://linuxcontainers.org
Source: http://linuxcontainers.org/downloads/%{name}-%{version}.tar.gz
-Summary: %{name} : Linux Container
+Summary: Linux Containers userspace tools
Group: Applications/System
-License: LGPL
+License: LGPLv2+
BuildRoot: %{_tmppath}/%{name}-%{version}-build
-Requires: libcap openssl rsync
+Requires: openssl rsync
BuildRequires: libcap libcap-devel docbook2X
-%define with_python %{?_with_python: 1} %{?!_with_python: 0}
%if %{with_python}
Requires: python3
BuildRequires: python3-devel
%endif
-%define with_lua %{?_with_lua: 1} %{?!_with_lua: 0}
-%if %{with_lua}
-Requires: lua-filesystem
-BuildRequires: lua-devel
-%endif
-
%description
-
-The package %{name} provides the command lines to create and manage
-containers. It contains a full featured container with the isolation
-/ virtualization of the pids, the ipc, the utsname, the mount points,
-/proc, /sys, the network and it takes into account the control groups.
-It is very light, flexible, and provides a set of tools around the
-container like the monitoring with asynchronous events notification,
-or the freeze of the container. This package is useful to create
-Virtual Private Server, or to run isolated applications like bash or
-sshd.
-
-%packagelibs
-Summary:runtime library files for %{name}
-Group: System Environment/Libraries
-
-%descriptionlibs
+Containers are insulated areas inside a system, which have their own namespace
+for filesystem, network, PID, IPC, CPU and memory allocation and which can be
+created using the Control Group and Namespace features included in the Linux
+kernel.
+
+This package provides the lxc-* tools, which can be used to start a single
+daemon in a container, or to boot an entire containerized system, and to
+manage and debug your containers.
+
+%package libs
+Summary: Shared library files for %{name}
+Group: System Environment/Libraries
+%description libs
The %{name}-libs package contains libraries for running %{name} applications.
-%package devel
-Summary: development library for %{name}
-Group: Development/Libraries
-
-%description devel
+%package devel
+Summary: Development library for %{name}
+Group: Development/Libraries
+Requires: %{name} = %{version}-%{release}, pkgconfig
+%description devel
The %{name}-devel package contains header files and library needed for
-development of the linux containers.
+development of the Linux containers.
+
+%if %{with_lua}
+%package lua
+Summary: Lua bindings for %{name}
+Group: System Environment/Libraries
+Requires: lua-filesystem
+BuildRequires: lua-devel
+%description lua
+The %{name}-lua package contains %{name} bindings for lua.
+%endif
%prep
-%setup
+%setup -q
%build
PATH=$PATH:/usr/sbin:/sbin %configure $args \
%if %{with_lua}
@@ -93,6 +96,8 @@ find %{buildroot} -type f -name '*.la' -exec rm -f {} ';'
rm -rf %{buildroot}
%post
+%post libs -p /sbin/ldconfig
+%postun libs -p /sbin/ldconfig
%files
%defattr(-,root,root)
@@ -106,25 +111,33 @@ rm -rf %{buildroot}
%attr(4111,root,root) %{_bindir}/lxc-execute
%attr(4111,root,root) %{_bindir}/lxc-checkpoint
%attr(4111,root,root) %{_bindir}/lxc-restart
-%{_mandir}/*
+%{_mandir}/man1/lxc*
+%{_mandir}/man5/lxc*
+%{_mandir}/man7/lxc*
+%{_mandir}/ja/man1/lxc*
+%{_mandir}/ja/man5/lxc*
+%{_mandir}/ja/man7/lxc*
%{_datadir}/doc/*
%{_datadir}/lxc/*
-%{_sysconfdir}/lxc/*
+%config(noreplace) %{_sysconfdir}/lxc/*
%files libs
%defattr(-,root,root)
%{_libdir}/*.so.*
%{_libdir}/%{name}
-%if %{with_lua}
Re: [lxc-devel] [PATCH] install lua module 0644 instead of 0755
On Tue, Oct 22, 2013 at 04:33:34PM -0400, Dwight Engen wrote: Fixes rpmlint error script-without-shebang. Checked other lua modules and none are installed with execute permission. Signed-off-by: Dwight Engen dwight.en...@oracle.com Acked-by: Stéphane Graber stgra...@ubuntu.com --- src/lua-lxc/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/lua-lxc/Makefile.am b/src/lua-lxc/Makefile.am index 11eabfd..7bbaf61 100644 --- a/src/lua-lxc/Makefile.am +++ b/src/lua-lxc/Makefile.am @@ -3,7 +3,7 @@ if ENABLE_LUA luadir=$(LUA_INSTALL_LMOD) sodir=$(LUA_INSTALL_CMOD)/lxc -lua_SCRIPTS=lxc.lua +lua_DATA=lxc.lua so_PROGRAMS = core.so -- 1.8.3.1 -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel -- Stéphane Graber Ubuntu developer http://www.ubuntu.com signature.asc Description: Digital signature -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] update rpm .spec file
On Tue, Oct 22, 2013 at 04:33:26PM -0400, Dwight Engen wrote:
The following changes were made to fix rpmlint warnings/errors
- use %global instead of %define
http://fedoraproject.org/wiki/PackagingDrafts/global_preferred_over_define
- change Summary to match .deb
- update License
- do not mention the libcap dependency explicitly, rpm will fill it in
- fix Summary, Description for libs and devel packages
- pass -q to %setup
- add %post for libs to run ldconfig
- explicitly name lxc man paths so pkg doesn't own /usr/share/man
- mark /etc/lxc/default.conf as a config file
In addition, while I was here:
- split lua bits into seperate lxc-lua package
- change Description to match .deb
- remove Version in changelog entries to follow
http://fedoraproject.org/wiki/Packaging:Guidelines#Changelogs
Signed-off-by: Dwight Engen dwight.en...@oracle.com
Acked-by: Stéphane Graber stgra...@ubuntu.com
---
lxc.spec.in | 109
+++-
1 file changed, 63 insertions(+), 46 deletions(-)
diff --git a/lxc.spec.in b/lxc.spec.in
index a0f2c1a..f4bcd8c 100644
--- a/lxc.spec.in
+++ b/lxc.spec.in
@@ -20,59 +20,62 @@
# License along with this library; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
USA
+%global with_python %{?_with_python: 1} %{?!_with_python: 0}
+%global with_lua %{?_with_lua: 1} %{?!_with_lua: 0}
+
Name: @PACKAGE@
Version: @VERSION@
Release: 1%{?dist}
URL: http://linuxcontainers.org
Source: http://linuxcontainers.org/downloads/%{name}-%{version}.tar.gz
-Summary: %{name} : Linux Container
+Summary: Linux Containers userspace tools
Group: Applications/System
-License: LGPL
+License: LGPLv2+
BuildRoot: %{_tmppath}/%{name}-%{version}-build
-Requires: libcap openssl rsync
+Requires: openssl rsync
BuildRequires: libcap libcap-devel docbook2X
-%define with_python %{?_with_python: 1} %{?!_with_python: 0}
%if %{with_python}
Requires: python3
BuildRequires: python3-devel
%endif
-%define with_lua %{?_with_lua: 1} %{?!_with_lua: 0}
-%if %{with_lua}
-Requires: lua-filesystem
-BuildRequires: lua-devel
-%endif
-
%description
-
-The package %{name} provides the command lines to create and manage
-containers. It contains a full featured container with the isolation
-/ virtualization of the pids, the ipc, the utsname, the mount points,
-/proc, /sys, the network and it takes into account the control groups.
-It is very light, flexible, and provides a set of tools around the
-container like the monitoring with asynchronous events notification,
-or the freeze of the container. This package is useful to create
-Virtual Private Server, or to run isolated applications like bash or
-sshd.
-
-%packagelibs
-Summary:runtime library files for %{name}
-Group: System Environment/Libraries
-
-%descriptionlibs
+Containers are insulated areas inside a system, which have their own
namespace
+for filesystem, network, PID, IPC, CPU and memory allocation and which can
be
+created using the Control Group and Namespace features included in the Linux
+kernel.
+
+This package provides the lxc-* tools, which can be used to start a single
+daemon in a container, or to boot an entire containerized system, and to
+manage and debug your containers.
+
+%package libs
+Summary: Shared library files for %{name}
+Group: System Environment/Libraries
+%description libs
The %{name}-libs package contains libraries for running %{name} applications.
-%package devel
-Summary: development library for %{name}
-Group: Development/Libraries
-
-%description devel
+%package devel
+Summary: Development library for %{name}
+Group: Development/Libraries
+Requires:%{name} = %{version}-%{release}, pkgconfig
+%description devel
The %{name}-devel package contains header files and library needed for
-development of the linux containers.
+development of the Linux containers.
+
+%if %{with_lua}
+%package lua
+Summary: Lua bindings for %{name}
+Group: System Environment/Libraries
+Requires:lua-filesystem
+BuildRequires: lua-devel
+%description lua
+The %{name}-lua package contains %{name} bindings for lua.
+%endif
%prep
-%setup
+%setup -q
%build
PATH=$PATH:/usr/sbin:/sbin %configure $args \
%if %{with_lua}
@@ -93,6 +96,8 @@ find %{buildroot} -type f -name '*.la' -exec rm -f {} ';'
rm -rf %{buildroot}
%post
+%post libs -p /sbin/ldconfig
+%postun libs -p /sbin/ldconfig
%files
%defattr(-,root,root)
@@ -106,25 +111,33 @@ rm -rf %{buildroot}
%attr(4111,root,root) %{_bindir}/lxc-execute
%attr(4111,root,root) %{_bindir}/lxc-checkpoint
%attr(4111,root,root) %{_bindir}/lxc-restart
-%{_mandir}/*
+%{_mandir}/man1/lxc*
+%{_mandir}/man5/lxc*
+%{_mandir}/man7/lxc*
Re: [lxc-devel] Kernel bug? Setuid apps and user namespaces
On 10/22/2013 03:50 PM, Eric W. Biederman wrote:
Serge Hallyn serge.hal...@ubuntu.com writes:
Quoting Sean Pajot (sean.pa...@execulink.com):
I've been playing with User Namespaces somewhat extensively and I think I've
come across a bug in the handling of /proc/$PID/ entries.
This is my example case on a 3.10.x kernel:
-- /var/lib/lxc/test1/config
lxc.rootfs = /lxc/c1
lxc.id_map = u 0 100 10
lxc.id_map = g 0 100 10
lxc.network.type = none
lxc.tty = 6
== END
On one console login as a non-root user and run su, as an example of a
setuid root application. On another console login as root and examine
/proc/$(pidof su). You'll find all the files are owned by the nobody user
and inaccessible. The reason is on the host you'll find these files are
owned
by root, uid 0, which is odd because in the container they should be uid
100 from the mappings.
I tracked down the cause to kernel source file /fs/proc/base.c function
pid_revalidate which contains static references to GLOBAL_ROOT_UID and
GLOBAL_ROOT_GID which are always UID 0 on the host. This little patch, which
might not be correct in terms of kernel standards, appears to mostly solve
the
issue. It doesn't affect all entries in /proc/$PID but gets the majority of
them.
Thoughts or opinions?
Awesome - I've seen this bug and so far not had time to dig.
The patch offhand looks good to me. Do you mind sending it to
lkml?
Acked-by: Serge E. Hallyn serge.hal...@ubuntu.com
Well I wasn't expecting that... :)
It is definitely worth looking at. I punted on this when I did the
initial round of conversions. Tasks that we don't consider dumpable are
weird.
At first glance this fine. However __task_cred does not return NULL so
handling that case is nonsense and confusing.
Eric
I thought so, but I wanted to have a failsafe since I'm running this code on
the same machine I'm typing this message on.
This is my first patch that had a chance of making it into the kernel so I'm
honestly making things up as I go. I put that there so in the event a NULL
cred showed up there would be known symptoms besides an Oops.
On my system I still have the ns directory marked as owned by host's uid 0
but since the permissions are 511 (?) and the namespace objects are owned by
container's uid 0 it doesn't really impact much. That could probably use
fixing but the use cases are generally usable now.
That aside, you really think it's okay for inclusion in the kernel with
cred!=NULL fixed?
--- linux-3.10-clean/fs/proc/base.c 2013-06-30 18:13:29.0 -0400
+++ linux-3.10-patched/fs/proc/base.c 2013-10-22 13:28:22.561262197
-0400
@@ -1632,17 +1632,17 @@
task = get_proc_task(inode);
if (task) {
+ rcu_read_lock();
+ cred = __task_cred(task);
if ((inode-i_mode == (S_IFDIR|S_IRUGO|S_IXUGO)) ||
task_dumpable(task)) {
- rcu_read_lock();
- cred = __task_cred(task);
inode-i_uid = cred-euid;
inode-i_gid = cred-egid;
- rcu_read_unlock();
} else {
- inode-i_uid = GLOBAL_ROOT_UID;
- inode-i_gid = GLOBAL_ROOT_GID;
+ inode-i_uid = cred ? make_kuid(cred-user_ns, 0) :
GLOBAL_ROOT_UID;
+ inode-i_gid = cred ? make_kgid(cred-user_ns, 0) :
GLOBAL_ROOT_GID;
}
+ rcu_read_unlock();
inode-i_mode = ~(S_ISUID | S_ISGID);
security_task_to_inode(task, inode);
put_task_struct(task);
--
execulink
TELECOM
Sean Pajot
System Administrator
1127 Ridgeway Rd, Woodstock
tel: 519.456.7249
email: sean.pa...@execulink.com
www.execulink.ca
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [lxc/lxc] 72e992: Pass through all options with -Bbest.
Branch: refs/heads/master Home: https://github.com/lxc/lxc Commit: 72e99249b0c03c283bf68a3334d70a74fee49f34 https://github.com/lxc/lxc/commit/72e99249b0c03c283bf68a3334d70a74fee49f34 Author: Sidnei da Silva sidnei.da.si...@canonical.com Date: 2013-10-22 (Tue, 22 Oct 2013) Changed paths: M src/lxc/bdev.c M src/lxc/bdev.h M src/lxc/lxc_create.c Log Message: --- Pass through all options with -Bbest. Remove the union in bdev_specs and store all options if -Bbest is passed. Fixes issue #31. Signed-off-by: Sidnei da Silva sidnei.da.si...@canonical.com Signed-off-by: Serge Hallyn serge.hal...@ubuntu.com Commit: 47b6e6cff0b5431494cd41f94c2c0629cf5e41a8 https://github.com/lxc/lxc/commit/47b6e6cff0b5431494cd41f94c2c0629cf5e41a8 Author: Serge Hallyn serge.hal...@ubuntu.com Date: 2013-10-22 (Tue, 22 Oct 2013) Changed paths: M src/lxc/bdev.c Log Message: --- bdev.c: don't free right before exit Also log execlp error code if it returns. Signed-off-by: Serge Hallyn serge.hal...@ubuntu.com Compare: https://github.com/lxc/lxc/compare/3ffe454baf94...47b6e6cff0b5 -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [PATCH 1/3] container creation: support unpriv container creation in user namespaces
From: Serge Hallyn serge.hal...@ubuntu.com
1. lxcapi_create: don't try to unshare and mount for dir backed containers
It's unnecessary, and breaks unprivileged lxc-create (since unpriv users
cannot yet unshare(CLONE_NEWNS)).
2. api_create: chown rootfs
chown rootfs to the host uid to which container root will be mapped
3. create: run template in a mapped user ns
4. use (setuid-root) newxidmap to set id_map if we are not root
This is needed to be able to set userns mappings as an unprivileged
user, for unprivileged lxc-start.
Signed-off-by: Serge Hallyn serge.hal...@ubuntu.com
---
src/lxc/conf.c | 102 +-
src/lxc/conf.h | 4 ++
src/lxc/lxccontainer.c | 164 -
3 files changed, 240 insertions(+), 30 deletions(-)
diff --git a/src/lxc/conf.c b/src/lxc/conf.c
index 208c08b..3f7f0ef 100644
--- a/src/lxc/conf.c
+++ b/src/lxc/conf.c
@@ -2802,31 +2802,49 @@ int lxc_map_ids(struct lxc_list *idmap, pid_t pid)
int ret = 0;
enum idtype type;
char *buf = NULL, *pos;
+ int am_root = (getuid() == 0);
for(type = ID_TYPE_UID; type = ID_TYPE_GID; type++) {
int left, fill;
-
- pos = buf;
- lxc_list_for_each(iterator, idmap) {
- /* The kernel only takes = 4k for writes to
/proc/nr/[ug]id_map */
- if (!buf)
- buf = pos = malloc(4096);
+ int had_entry = 0;
+ if (!buf) {
+ buf = pos = malloc(4096);
if (!buf)
return -ENOMEM;
+ }
+ pos = buf;
+ if (!am_root)
+ pos += sprintf(buf, new%cidmap %d ,
+ type == ID_TYPE_UID ? 'u' : 'g',
+ pid);
+ lxc_list_for_each(iterator, idmap) {
+ /* The kernel only takes = 4k for writes to
/proc/nr/[ug]id_map */
map = iterator-elem;
- if (map-idtype == type) {
- left = 4096 - (pos - buf);
- fill = snprintf(pos, left, %lu %lu %lu\n,
- map-nsid, map-hostid, map-range);
- if (fill = 0 || fill = left)
- SYSERROR(snprintf failed, too many
mappings);
- pos += fill;
- }
+ if (map-idtype != type)
+ continue;
+
+ had_entry = 1;
+ left = 4096 - (pos - buf);
+ fill = snprintf(pos, left, %lu %lu %lu, map-nsid,
+ map-hostid, map-range);
+ if (fill = 0 || fill = left)
+ SYSERROR(snprintf failed, too many mappings);
+ pos += fill;
}
- if (pos == buf) // no mappings were found
+ if (!had_entry)
continue;
- ret = write_id_mapping(type, pid, buf, pos-buf);
+ left = 4096 - (pos - buf);
+ fill = snprintf(pos, left, \n);
+ if (fill = 0 || fill = left)
+ SYSERROR(snprintf failed, too many mappings);
+ pos += fill;
+
+ if (am_root)
+ ret = write_id_mapping(type, pid, buf, pos-buf);
+ else
+ ret = system(buf);
+
if (ret)
break;
}
@@ -2836,6 +2854,58 @@ int lxc_map_ids(struct lxc_list *idmap, pid_t pid)
return ret;
}
+/*
+ * return the host uid to which the container root is mapped, or -1 on
+ * error
+ */
+int get_mapped_rootid(struct lxc_conf *conf)
+{
+ struct lxc_list *it;
+ struct id_map *map;
+
+ lxc_list_for_each(it, conf-id_map) {
+ map = it-elem;
+ if (map-idtype != ID_TYPE_UID)
+ continue;
+ if (map-nsid != 0)
+ continue;
+ return map-hostid;
+ }
+ return -1;
+}
+
+bool hostid_is_mapped(int id, struct lxc_conf *conf)
+{
+ struct lxc_list *it;
+ struct id_map *map;
+ lxc_list_for_each(it, conf-id_map) {
+ map = it-elem;
+ if (map-idtype != ID_TYPE_UID)
+ continue;
+ if (id = map-hostid id map-hostid + map-range)
+ return true;
+ }
+ return false;
+}
+
+int find_unmapped_nsuid(struct lxc_conf *conf)
+{
+ struct lxc_list *it;
+ struct id_map *map;
+ uid_t freeid = 0;
+again:
+ lxc_list_for_each(it, conf-id_map) {
+ map = it-elem;
+
[lxc-devel] unprivileged create/start
These patches address a few of the issues with creating and running containers without privilege. They are only a start. On an ubuntu trusty system (with a device_cgroup kernel patch) I can now do the following: # one-time system setup sudo apt-get -y install uidmap sudo usermod -v 10-19 -w 10-19 serge mkdir ~/lxcbase cat lxc.conf EOF lxc.network.type = empty lxc.id_map = u 0 10 1 lxc.id_map = g 0 10 1 #EOF # per-boot setup echo 1 | sudo tee -a /sys/fs/cgroup/cpuset/cgroup.clone_children for d in /sys/fs/cgroup/*; do sudo mkdir $d/serge chown serge: $d/serge done # login setup for d in /sys/fs/cgroup/*; do echo $$ | sudo tee -a $d/serge/tasks done # create a busybox container lxc-create -P /home/serge/lxcbase -t busybox -n b1 -f lxc.conf # run it lxc-start -P /home/serge/lxcbase -n b1 # or run it in the background lxc-start -P /home/serge/lxcbase -n b1 -d # attach a console lxc-console -P /home/serge/lxcbase -n b1 # kill it lxc-stop -P /home/serge/lxcbase -n b1 TO DO: 1. get the ubuntu-cloud template working. a. To avoid tar failing due to devices, we can simply require root to create new cloud image tarballs with no devices (mkdir x; cd x; sudo tar zxf /var/cache/lxc/cloud-saucy/*; sudo rm -rf dev/*; sudo mkdir dev/pts; sudo tar pzcf ../cloud.tar.gz .) or we can do '|| true' after the tar. Are there any other good options? b. fix assumptions in the template that we can write to @LOCALESTATEDIR@ 2. implement networking using lxc-user-nic -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [PATCH 2/3] fix chowning of tty and console uids
From: Serge Hallyn serge.hal...@ubuntu.com
It needs to be done from the handler, not the container, since
the container may not have the rights.
Signed-off-by: Serge Hallyn serge.hal...@ubuntu.com
Changelog:
Jul 22: remove hardcoded path for /bin/chown
Jul 22: use new lxc-usernsexec
Conflicts:
src/lxc/lxccontainer.c
---
src/lxc/conf.c | 126 +++--
src/lxc/conf.h | 6 +--
src/lxc/lxccontainer.c | 54 +
src/lxc/start.c| 10 ++--
4 files changed, 69 insertions(+), 127 deletions(-)
diff --git a/src/lxc/conf.c b/src/lxc/conf.c
index 3f7f0ef..bba6379 100644
--- a/src/lxc/conf.c
+++ b/src/lxc/conf.c
@@ -2858,7 +2858,7 @@ int lxc_map_ids(struct lxc_list *idmap, pid_t pid)
* return the host uid to which the container root is mapped, or -1 on
* error
*/
-int get_mapped_rootid(struct lxc_conf *conf)
+uid_t get_mapped_rootid(struct lxc_conf *conf)
{
struct lxc_list *it;
struct id_map *map;
@@ -2869,9 +2869,9 @@ int get_mapped_rootid(struct lxc_conf *conf)
continue;
if (map-nsid != 0)
continue;
- return map-hostid;
+ return (uid_t) map-hostid;
}
- return -1;
+ return (uid_t)-1;
}
bool hostid_is_mapped(int id, struct lxc_conf *conf)
@@ -3020,89 +3020,81 @@ void lxc_delete_tty(struct lxc_tty_info *tty_info)
}
/*
- * given a host uid, return the ns uid if it is mapped.
- * if it is not mapped, return the original host id.
+ * chown_mapped_root: for an unprivileged user with uid X to chown a dir
+ * to subuid Y, he needs to run chown as root in a userns where
+ * nsid 0 is mapped to hostuid Y, and nsid Y is mapped to hostuid
+ * X. That way, the container root is privileged with respect to
+ * hostuid X, allowing him to do the chown.
*/
-static int shiftid(struct lxc_conf *c, int uid, enum idtype w)
+int chown_mapped_root(char *path, struct lxc_conf *conf)
{
- struct lxc_list *iterator;
- struct id_map *map;
- int low, high;
+ uid_t rootid;
+ pid_t pid;
- lxc_list_for_each(iterator, c-id_map) {
- map = iterator-elem;
- if (map-idtype != w)
- continue;
-
- low = map-nsid;
- high = map-nsid + map-range;
- if (uid low || uid = high)
- continue;
-
- return uid - low + map-hostid;
+ if ((rootid = get_mapped_rootid(conf)) = 0) {
+ ERROR(No mapping for container root);
+ return -1;
}
-
- return uid;
-}
-
-/*
- * Take a pathname for a file created on the host, and map the uid and gid
- * into the container if needed. (Used for ttys)
- */
-static int uid_shift_file(char *path, struct lxc_conf *c)
-{
- struct stat statbuf;
- int newuid, newgid;
-
- if (stat(path, statbuf)) {
- SYSERROR(stat(%s), path);
+ if (geteuid() == 0) {
+ if (chown(path, rootid, -1) 0) {
+ ERROR(Error chowning %s, path);
+ return -1;
+ }
+ return 0;
+ }
+ pid = fork();
+ if (pid 0) {
+ SYSERROR(Failed forking);
return -1;
}
+ if (!pid) {
+ int hostuid = geteuid(), ret;
+ char map1[100], map2[100];
+ char *args[] = {lxc-usernsexec, -m, map1, -m, map2, --,
chown,
+0, path, NULL};
- newuid = shiftid(c, statbuf.st_uid, ID_TYPE_UID);
- newgid = shiftid(c, statbuf.st_gid, ID_TYPE_GID);
- if (newuid != statbuf.st_uid || newgid != statbuf.st_gid) {
- DEBUG(chowning %s from %d:%d to %d:%d\n, path,
(int)statbuf.st_uid, (int)statbuf.st_gid, newuid, newgid);
- if (chown(path, newuid, newgid)) {
- SYSERROR(chown(%s), path);
+ // b:0:rootid:1
+ ret = snprintf(map1, 100, b:0:%d:1, rootid);
+ if (ret 0 || ret = 100) {
+ ERROR(Error uid printing map string);
return -1;
}
+
+ // b:hostuid:hostuid:1
+ ret = snprintf(map2, 100, b:%d:%d:1, hostuid, hostuid);
+ if (ret 0 || ret = 100) {
+ ERROR(Error uid printing map string);
+ return -1;
+ }
+
+ ret = execvp(lxc-usernsexec, args);
+ SYSERROR(Failed executing usernsexec);
+ exit(1);
}
- return 0;
+ return wait_for_pid(pid);
}
-int uid_shift_ttys(int pid, struct lxc_conf *conf)
+int ttys_shift_ids(struct lxc_conf *c)
{
- int i, ret;
- struct lxc_tty_info *tty_info = conf-tty_info;
- char path[MAXPATHLEN];
- char *ttydir = conf-ttydir;
+ int
[lxc-devel] [PATCH 3/3] lxc-busybox: if in userns, don't try to mknod
From: Serge Hallyn serge.hal...@ubuntu.com
Signed-off-by: Serge Hallyn serge.hal...@ubuntu.com
---
templates/lxc-busybox.in | 44 +++-
1 file changed, 31 insertions(+), 13 deletions(-)
diff --git a/templates/lxc-busybox.in b/templates/lxc-busybox.in
index cbdaaf3..7aa4130 100644
--- a/templates/lxc-busybox.in
+++ b/templates/lxc-busybox.in
@@ -20,6 +20,17 @@
# License along with this library; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+am_in_userns() {
+[ -e /proc/self/uid_map ] || { echo no; return; }
+[ $(wc -l /proc/self/uid_map | awk '{ print $1 }') -eq 1 ] || { echo
yes; return; }
+line=$(awk '{ print $1 $2 $3 }' /proc/self/uid_map)
+[ $line = 0 0 4294967295 ] { echo no; return; }
+echo yes
+}
+
+in_userns=0
+[ $(am_in_userns) = yes ] in_userns=1
+
install_busybox()
{
rootfs=$1
@@ -55,19 +66,26 @@ $rootfs/usr/lib64
pushd $rootfs/dev /dev/null || return 1
# minimal devices needed for busybox
-mknod tty c 5 0 || res=1
-mknod console c 5 1 || res=1
-chmod 666 tty console || res=1
-mknod tty0 c 4 0 || res=1
-mknod tty1 c 4 0 || res=1
-mknod tty5 c 4 0 || res=1
-chmod 666 tty0|| res=1
-mknod ram0 b 1 0 || res=1
-chmod 600 ram0|| res=1
-mknod null c 1 3 || res=1
-chmod 666 null|| res=1
-mknod urandom c 1 9 || res=1
-chmod 666 urandom || res=1
+if [ $in_userns -eq 1 ]; then
+for dev in tty console tty0 tty1 tty5 ram0 null urandom; do
+touch $rootfs/dev/$dev
+echo /dev/$dev dev/$devnone bind 0 0 $path/fstab
+done
+else
+mknod tty c 5 0 || res=1
+mknod console c 5 1 || res=1
+chmod 666 tty console || res=1
+mknod tty0 c 4 0 || res=1
+mknod tty1 c 4 0 || res=1
+mknod tty5 c 4 0 || res=1
+chmod 666 tty0|| res=1
+mknod ram0 b 1 0 || res=1
+chmod 600 ram0|| res=1
+mknod null c 1 3 || res=1
+chmod 666 null|| res=1
+mknod urandom c 1 9 || res=1
+chmod 666 urandom || res=1
+fi
popd /dev/null
--
1.8.1.2
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] Kernel bug? Setuid apps and user namespaces
Sean Pajot sean.pa...@execulink.com writes:
On 10/22/2013 03:50 PM, Eric W. Biederman wrote:
Serge Hallyn serge.hal...@ubuntu.com writes:
Quoting Sean Pajot (sean.pa...@execulink.com):
I've been playing with User Namespaces somewhat extensively and I think
I've
come across a bug in the handling of /proc/$PID/ entries.
This is my example case on a 3.10.x kernel:
-- /var/lib/lxc/test1/config
lxc.rootfs = /lxc/c1
lxc.id_map = u 0 100 10
lxc.id_map = g 0 100 10
lxc.network.type = none
lxc.tty = 6
== END
On one console login as a non-root user and run su, as an example of a
setuid root application. On another console login as root and examine
/proc/$(pidof su). You'll find all the files are owned by the nobody user
and inaccessible. The reason is on the host you'll find these files are
owned
by root, uid 0, which is odd because in the container they should be uid
100 from the mappings.
I tracked down the cause to kernel source file /fs/proc/base.c function
pid_revalidate which contains static references to GLOBAL_ROOT_UID and
GLOBAL_ROOT_GID which are always UID 0 on the host. This little patch,
which
might not be correct in terms of kernel standards, appears to mostly solve
the
issue. It doesn't affect all entries in /proc/$PID but gets the majority
of them.
Thoughts or opinions?
Awesome - I've seen this bug and so far not had time to dig.
The patch offhand looks good to me. Do you mind sending it to
lkml?
Acked-by: Serge E. Hallyn serge.hal...@ubuntu.com
Well I wasn't expecting that... :)
It is definitely worth looking at. I punted on this when I did the
initial round of conversions. Tasks that we don't consider dumpable are
weird.
At first glance this fine. However __task_cred does not return NULL so
handling that case is nonsense and confusing.
Eric
I thought so, but I wanted to have a failsafe since I'm running this code on
the same machine I'm typing this message on.
This is my first patch that had a chance of making it into the kernel so I'm
honestly making things up as I go. I put that there so in the event a NULL
cred showed up there would be known symptoms besides an Oops.
On my system I still have the ns directory marked as owned by host's uid 0
but since the permissions are 511 (?) and the namespace objects are owned by
container's uid 0 it doesn't really impact much. That could probably use
fixing but the use cases are generally usable now.
That aside, you really think it's okay for inclusion in the kernel with
cred!=NULL fixed?
Someone needs to read and think through all of the corner cases and see
if we can ever have a time when task_dumpable is false but root in the
container would not or should not be able to see everything.
In particular I am worried about the case of a setuid app calling setns,
and entering a lesser privileged user namespace. In my foggy mind that
might be a security problem. And there might be other similar crazy
cases.
But the code itself looks good, and the bug hunting seems solid.
If my concerns about a setuid app calling setns are valid what we can
likely do with dumpable is record the kuid of the userns root when the
task becomes non-dumpable, and use that for i_uid and i_gid.
Eric
--- linux-3.10-clean/fs/proc/base.c2013-06-30 18:13:29.0
-0400
+++ linux-3.10-patched/fs/proc/base.c 2013-10-22 13:28:22.561262197
-0400
@@ -1632,17 +1632,17 @@
task = get_proc_task(inode);
if (task) {
+ rcu_read_lock();
+ cred = __task_cred(task);
if ((inode-i_mode == (S_IFDIR|S_IRUGO|S_IXUGO)) ||
task_dumpable(task)) {
- rcu_read_lock();
- cred = __task_cred(task);
inode-i_uid = cred-euid;
inode-i_gid = cred-egid;
- rcu_read_unlock();
} else {
- inode-i_uid = GLOBAL_ROOT_UID;
- inode-i_gid = GLOBAL_ROOT_GID;
+ inode-i_uid = cred ? make_kuid(cred-user_ns, 0) :
GLOBAL_ROOT_UID;
+ inode-i_gid = cred ? make_kgid(cred-user_ns, 0) :
GLOBAL_ROOT_GID;
}
+ rcu_read_unlock();
inode-i_mode = ~(S_ISUID | S_ISGID);
security_task_to_inode(task, inode);
put_task_struct(task);
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
