From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Emelyanov Subject: Re: namespaces compatibility list Date: Tue, 06 Nov 2007 20:09:01 +0300 Message-ID: <47309FAD.90702@openvz.org> 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=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: 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: "Eric W. Biederman" , Cedric Le Goater Cc: Linux Containers List-Id: containers.vger.kernel.org Eric W. Biederman wrote: > 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. ACK :) Since this all is CAP_SYS_ADMIN-ed we can do with just a warning. > Eric >