From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman) Subject: Re: namespaces compatibility list Date: Tue, 06 Nov 2007 10:00:27 -0700 Message-ID: References: <47304729.8000309@openvz.org> <4730640D.9030407@fr.ibm.com> <4730655C.8000306@openvz.org> <47308FDB.4010302@fr.ibm.com> <473091F9.10406@openvz.org> <47309A51.1050607@fr.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: In-Reply-To: <47309A51.1050607-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org> (Cedric Le Goater's message of "Tue, 06 Nov 2007 17:46:09 +0100") List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Cedric Le Goater Cc: Linux Containers , Pavel Emelyanov List-Id: containers.vger.kernel.org Cedric Le Goater writes: > right. I think we can address Ulrich concerns first because we have > a solution for it (which looks like unsharing all namespaces at once, > here comes back the container object story :) It doesn't work because we can't create a fresh mount namespace. We need to create all new mounts (and deny access to the old ones) if we want to prevent all possibility of user space goof ups. While that is easy enough to build an application to do we can't easily enforce that in the kernel. Currently this is all CAP_SYS_ADMIN so only root can do this anyway. So we can easily say don't do that then. Clone flag consistency checking should only be used to enforce cases where the kernel side cannot support correctly. Currently the kernel has no problems with the current mix and match possibilities short of implementation deficiencies. So I do not see us addressing Ulrich's concerns with clone flags. Eric