Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261548AbVEPLPT (ORCPT ); Mon, 16 May 2005 07:15:19 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261541AbVEPLPS (ORCPT ); Mon, 16 May 2005 07:15:18 -0400 Received: from mail.shareable.org ([81.29.64.88]:6871 "EHLO mail.shareable.org") by vger.kernel.org with ESMTP id S261523AbVEPLOc (ORCPT ); Mon, 16 May 2005 07:14:32 -0400 Date: Mon, 16 May 2005 12:14:08 +0100 From: Jamie Lokier To: Ram Cc: Miklos Szeredi , viro@parcelfarce.linux.theplanet.co.uk, Andrew Morton , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH] namespace.c: fix bind mount from foreign namespace Message-ID: <20050516111408.GA21145@mail.shareable.org> References: <20050513170602.GI1150@parcelfarce.linux.theplanet.co.uk> <1116005355.6248.372.camel@localhost> <1116012287.6248.410.camel@localhost> <1116013840.6248.429.camel@localhost> <1116256279.4154.41.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1116256279.4154.41.camel@localhost> User-Agent: Mutt/1.4.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1353 Lines: 37 Ram wrote: > > I'd rather not speculate on what Al Viro was thinking, it may have > > been just a misunderstanding. > > Can somebody who know internals of Al Viro's thinking help here? Presumably he wrote this line: if (check_mnt(nd->mnt) && (!recurse || check_mnt(old_nd.mnt))) { Which /explicitly/ permits bind mounts between namespaces if it's not recursive. It's not accidental: that !recurse is blatantly making a point of allowing it. I take that to mean that /at least at one time/ Al chose to allow it. Then again, he also wrote this: > > Bind mount from a foreign namespace results in > > ... -EINVAL Which means that /at another time/ Al thought he'd disallowed it. This is a bit like arguing over what the Founding Fathers of the US Constitution meant. Does it matter? We really should ask what behaviour makes sense now. Should we add more explicit restrictions to the code, making the concept of namespaces more restrictive? Or remove the restrictions, on the grounds that they don't really add any security, it'd be useful to relax them, and the code would be simpler? -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/