From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161358AbXDQSUr (ORCPT ); Tue, 17 Apr 2007 14:20:47 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1161356AbXDQSUq (ORCPT ); Tue, 17 Apr 2007 14:20:46 -0400 Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:39406 "EHLO ebiederm.dsl.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161337AbXDQSUp (ORCPT ); Tue, 17 Apr 2007 14:20:45 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Miklos Szeredi Cc: serue@us.ibm.com, linuxram@us.ibm.com, linux-fsdevel@vger.kernel.org, viro@ftp.linux.org.uk, containers@lists.osdl.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org Subject: Re: [Devel] Re: [patch 05/10] add "permit user mounts in new namespace" clone flag References: <20070412164620.588752236@szeredi.hu> <20070412203208.GG27772@sergelap.austin.ibm.com> <1176713221.9488.17.camel@ram.us.ibm.com> <1176716941.9488.57.camel@ram.us.ibm.com> <20070416195652.GA350@sergelap.austin.ibm.com> Date: Tue, 17 Apr 2007 12:16:45 -0600 In-Reply-To: (Miklos Szeredi's message of "Tue, 17 Apr 2007 13:09:25 +0200") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Miklos Szeredi writes: > I'm still not sure, what your problem is. My problem right now is that I see a serious complexity escalation in the user interface that we must support indefinitely. I see us taking a nice powerful concept and seriously watering it down. To some extent we have to avoid confusing suid applications. (I would so love to remove the SUID bit...). I'm being contrary to ensure we have a good code review. I have heard it said that there are two kinds of design. Something so simple it obviously has no deficiencies. Something so complex it has no obvious deficiencies. I am very much afraid we are slipping the mount namespace into the latter category of work. Which is a bad bad thing for core OS feature. > With the v3 of the usermounts patchset, by default, user mounts are > disabled, because the "allow unpriv submounts" flag is cleared on all > mounts. > > There are several options available to sysadmins and distro builders > to enable user mounts in a secure way: > > - pam module, which creates a private namespace, and sets "allow > unpriv submounts" on the mounts within the namespace > > - pam module, which rbinds / onto /mnt/ns/$USER, and chroots into > /mnt/ns/$USER, then sets the "allow unpriv submounts" on the > mounts under /mnt/ns/$USER. In part this really disturbs me because we now have two mechanisms for controlling the scope of what a user can do. A flag or a new namespace. Two mechanisms to accomplish the same thing sound wrong, and hard to manage. > - sysadmin creates /mnt/usermounts writable to all users, with > sticky bit (same as /tmp), does "mount --bind /mnt/usermounts > /mnt/usermounts" and sets the "allow unpriv submounts" on > /mnt/usermounts. > > All of these are perfectly safe wrt userdel and backup (assuming it > doesn't try back up /mnt). I also don't understand at all the user= mount flag and options. All it seemed to be used for was adding permissions to unmount. In user space to deal with the lack of any form of untrusted mounts I can understand this. In kernel space this seems to be more of a problem. Eric