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

If we dont' do this patch, then we will need to move the apparmor attach
past the procfs remount, will need to also mount securityfs if available,
and for the !remount_proc_sys case we'll want to mount those just long
enough to do the apparmor transition.

Signed-off-by: Serge Hallyn <serge.hal...@ubuntu.com>
---
 src/lxc/lxc_attach.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/src/lxc/lxc_attach.c b/src/lxc/lxc_attach.c
index 1f60266..60d9eac 100644
--- a/src/lxc/lxc_attach.c
+++ b/src/lxc/lxc_attach.c
@@ -375,9 +375,11 @@ int main(int argc, char *argv[])
                lxc_sync_fini_parent(handler);
                close(cgroup_ipc_sockets[1]);
 
-               if (attach_apparmor(init_ctx->aa_profile) < 0) {
-                       ERROR("failed switching apparmor profiles");
-                       return -1;
+               if ((namespace_flags & CLONE_NEWNS)) {
+                       if (attach_apparmor(init_ctx->aa_profile) < 0) {
+                               ERROR("failed switching apparmor profiles");
+                               return -1;
+                       }
                }
 
                /* A description of the purpose of this functionality is
-- 
1.8.1.2


------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel

Reply via email to