From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262382AbVDXUIs@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262382AbVDXUIs (ORCPT <rfc822;willy@w.ods.org>);
	Sun, 24 Apr 2005 16:08:48 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262386AbVDXUIr
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 24 Apr 2005 16:08:47 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:22681 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S262382AbVDXUIb (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sun, 24 Apr 2005 16:08:31 -0400
To: linux-fsdevel@vger.kernel.org, hch@infradead.org
CC: linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: [PATCH] private mounts
Message-Id: <E1DPnOn-0000T0-00@localhost>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Sun, 24 Apr 2005 22:08:13 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

This simple patch adds support for private (or invisible) mounts.  The
rationale is to allow mounts to be private for a user but still in the
global namespace.

An immediate user of this would be FUSE, which currently achieves the
hiding of data with inode->permission(), which is less elegant.

Christoph, I'm specially interested in your opinion, since you were so
strongly opposed to the current solution in FUSE.

Performance measurements indicate that the overhead is about 2% of the
time spent following mounts, or 6ns per-mount on a 533 Celeron.

This patch does:

 - add new mount flag: MS_PRIVATE / MNT_PRIVATE
 - add new member in struct vfsmount: mnt_uid
 - if MNT_PRIVATE is set, set mnt_uid to current->fsuid in
   do_add_mount() and do_remount()
 - in clone_mnt() copy mnt_uid to the new mount
 - in lookup_mnt() while looping through the hash chain for the
   mountpoint, check if the mount is "visible" for this process, and
   skip it if not

Comments are appreciated.  If there are no vetoes agains the patch, I
think it's suitable for -mm.

Thanks,
Miklos

Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>

diff -rup orig/linux-2.6.11/fs/namespace.c linux-2.6.11/fs/namespace.c
--- orig/linux-2.6.11/fs/namespace.c	2005-03-04 23:18:48.000000000 +0100
+++ linux-2.6.11/fs/namespace.c	2005-04-24 12:44:41.000000000 +0200
@@ -81,6 +81,15 @@ void free_vfsmnt(struct vfsmount *mnt)
 }
 
 /*
+ * Check if this mount should be skipped or not
+ */
+static inline int mnt_visible(struct vfsmount *mnt)
+{
+	return !(mnt->mnt_flags & MNT_PRIVATE) ||
+		mnt->mnt_uid == current->fsuid;
+}
+
+/*
  * Now, lookup_mnt increments the ref count before returning
  * the vfsmount struct.
  */
@@ -97,7 +106,8 @@ struct vfsmount *lookup_mnt(struct vfsmo
 		if (tmp == head)
 			break;
 		p = list_entry(tmp, struct vfsmount, mnt_hash);
-		if (p->mnt_parent == mnt && p->mnt_mountpoint == dentry) {
+		if (p->mnt_parent == mnt && p->mnt_mountpoint == dentry &&
+		    mnt_visible(p)) {
 			found = mntget(p);
 			break;
 		}
@@ -155,6 +165,7 @@ clone_mnt(struct vfsmount *old, struct d
 
 	if (mnt) {
 		mnt->mnt_flags = old->mnt_flags;
+		mnt->mnt_uid = old->mnt_uid;
 		atomic_inc(&sb->s_active);
 		mnt->mnt_sb = sb;
 		mnt->mnt_root = dget(root);
@@ -234,6 +245,7 @@ static int show_vfsmnt(struct seq_file *
 		{ MNT_NOSUID, ",nosuid" },
 		{ MNT_NODEV, ",nodev" },
 		{ MNT_NOEXEC, ",noexec" },
+		{ MNT_PRIVATE, ",private" },
 		{ 0, NULL }
 	};
 	struct proc_fs_info *fs_infop;
@@ -252,6 +264,8 @@ static int show_vfsmnt(struct seq_file *
 		if (mnt->mnt_flags & fs_infop->flag)
 			seq_puts(m, fs_infop->str);
 	}
+	if (mnt->mnt_flags & MNT_PRIVATE)
+		seq_printf(m, ",mnt_uid=%u", mnt->mnt_uid);
 	if (mnt->mnt_sb->s_op->show_options)
 		err = mnt->mnt_sb->s_op->show_options(m, mnt);
 	seq_puts(m, " 0 0\n");
@@ -684,8 +698,11 @@ static int do_remount(struct nameidata *
 
 	down_write(&sb->s_umount);
 	err = do_remount_sb(sb, flags, data, 0);
-	if (!err)
+	if (!err) {
 		nd->mnt->mnt_flags=mnt_flags;
+		if (mnt_flags & MNT_PRIVATE)
+			nd->mnt->mnt_uid = current->fsuid;
+	}
 	up_write(&sb->s_umount);
 	if (!err)
 		security_sb_post_remount(nd->mnt, flags, data);
@@ -807,6 +824,8 @@ int do_add_mount(struct vfsmount *newmnt
 		goto unlock;
 
 	newmnt->mnt_flags = mnt_flags;
+	if (mnt_flags & MNT_PRIVATE)
+		newmnt->mnt_uid = current->fsuid;
 	err = graft_tree(newmnt, nd);
 
 	if (err == 0 && fslist) {
@@ -1033,7 +1052,9 @@ long do_mount(char * dev_name, char * di
 		mnt_flags |= MNT_NODEV;
 	if (flags & MS_NOEXEC)
 		mnt_flags |= MNT_NOEXEC;
-	flags &= ~(MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_ACTIVE);
+	if (flags & MS_PRIVATE)
+		mnt_flags |= MNT_PRIVATE;
+	flags &= ~(MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_PRIVATE|MS_ACTIVE);
 
 	/* ... and get the mountpoint */
 	retval = path_lookup(dir_name, LOOKUP_FOLLOW, &nd);
diff -rup orig/linux-2.6.11/include/linux/fs.h linux-2.6.11/include/linux/fs.h
--- orig/linux-2.6.11/include/linux/fs.h	2005-03-04 23:19:05.000000000 +0100
+++ linux-2.6.11/include/linux/fs.h	2005-04-24 10:23:33.000000000 +0200
@@ -96,6 +96,7 @@ extern int dir_notify_enable;
 #define MS_REMOUNT	32	/* Alter flags of a mounted FS */
 #define MS_MANDLOCK	64	/* Allow mandatory locks on an FS */
 #define MS_DIRSYNC	128	/* Directory modifications are synchronous */
+#define MS_PRIVATE	256	/* Make this mount invisible to other users */
 #define MS_NOATIME	1024	/* Do not update access times. */
 #define MS_NODIRATIME	2048	/* Do not update directory access times */
 #define MS_BIND		4096
diff -rup orig/linux-2.6.11/include/linux/mount.h linux-2.6.11/include/linux/mount.h
--- orig/linux-2.6.11/include/linux/mount.h	2004-12-25 11:52:55.000000000 +0100
+++ linux-2.6.11/include/linux/mount.h	2005-04-24 10:24:29.000000000 +0200
@@ -19,6 +19,7 @@
 #define MNT_NOSUID	1
 #define MNT_NODEV	2
 #define MNT_NOEXEC	4
+#define MNT_PRIVATE	8
 
 struct vfsmount
 {
@@ -31,6 +32,7 @@ struct vfsmount
 	struct list_head mnt_child;	/* and going through their mnt_child */
 	atomic_t mnt_count;
 	int mnt_flags;
+	uid_t mnt_uid;
 	int mnt_expiry_mark;		/* true if marked for expiry */
 	char *mnt_devname;		/* Name of device e.g. /dev/dsk/hda1 */
 	struct list_head mnt_list;

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262397AbVDXUNp@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262397AbVDXUNp (ORCPT <rfc822;willy@w.ods.org>);
	Sun, 24 Apr 2005 16:13:45 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262398AbVDXUNp
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 24 Apr 2005 16:13:45 -0400
Received: from parcelfarce.linux.theplanet.co.uk ([195.92.249.252]:59066 "EHLO
	parcelfarce.linux.theplanet.co.uk") by vger.kernel.org with ESMTP
	id S262375AbVDXUNn (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sun, 24 Apr 2005 16:13:43 -0400
Date: Sun, 24 Apr 2005 21:13:56 +0100
From: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: linux-fsdevel@vger.kernel.org, hch@infradead.org,
       linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050424201356.GJ13052@parcelfarce.linux.theplanet.co.uk>
References: <E1DPnOn-0000T0-00@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1DPnOn-0000T0-00@localhost>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Sun, Apr 24, 2005 at 10:08:13PM +0200, Miklos Szeredi wrote:
> Comments are appreciated.  If there are no vetoes agains the patch, I
> think it's suitable for -mm.

Vetoed.  Having suid application with different pathname resolution than
that of parent just because it is suid is not acceptable.  I'm sorry,
but breaking hell knows how many existing applications is not an option.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262398AbVDXUSg@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262398AbVDXUSg (ORCPT <rfc822;willy@w.ods.org>);
	Sun, 24 Apr 2005 16:18:36 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262402AbVDXUSg
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 24 Apr 2005 16:18:36 -0400
Received: from pentafluge.infradead.org ([213.146.154.40]:37770 "EHLO
	pentafluge.infradead.org") by vger.kernel.org with ESMTP
	id S262398AbVDXUS0 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sun, 24 Apr 2005 16:18:26 -0400
Date: Sun, 24 Apr 2005 21:18:20 +0100
From: Christoph Hellwig <hch@infradead.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: linux-fsdevel@vger.kernel.org, hch@infradead.org,
       linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050424201820.GA28428@infradead.org>
Mail-Followup-To: Christoph Hellwig <hch@infradead.org>,
	Miklos Szeredi <miklos@szeredi.hu>, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, akpm@osdl.org
References: <E1DPnOn-0000T0-00@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1DPnOn-0000T0-00@localhost>
User-Agent: Mutt/1.4.1i
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> by pentafluge.infradead.org
	See http://www.infradead.org/rpr.html
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Sun, Apr 24, 2005 at 10:08:13PM +0200, Miklos Szeredi wrote:
> This simple patch adds support for private (or invisible) mounts.  The
> rationale is to allow mounts to be private for a user but still in the
> global namespace.

As mentioned in the last -fsdevel thread a few times the idea of per-user
mounts is fundamentally flawed.  Crossing a namespace boundary must be
explicit - using clone or a new unshare() syscall.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262410AbVDXUqA@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262410AbVDXUqA (ORCPT <rfc822;willy@w.ods.org>);
	Sun, 24 Apr 2005 16:46:00 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262411AbVDXUqA
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 24 Apr 2005 16:46:00 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:33689 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S262410AbVDXUpy (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sun, 24 Apr 2005 16:45:54 -0400
To: viro@parcelfarce.linux.theplanet.co.uk
CC: linux-fsdevel@vger.kernel.org, hch@infradead.org,
       linux-kernel@vger.kernel.org, akpm@osdl.org
In-reply-to: <20050424201356.GJ13052@parcelfarce.linux.theplanet.co.uk>
	(message from Al Viro on Sun, 24 Apr 2005 21:13:56 +0100)
Subject: Re: [PATCH] private mounts
References: <E1DPnOn-0000T0-00@localhost> <20050424201356.GJ13052@parcelfarce.linux.theplanet.co.uk>
Message-Id: <E1DPnyx-0000Uf-00@localhost>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Sun, 24 Apr 2005 22:45:35 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> > Comments are appreciated.  If there are no vetoes agains the patch, I
> > think it's suitable for -mm.
> 
> Vetoed.  Having suid application with different pathname resolution than
> that of parent just because it is suid is not acceptable.  I'm sorry,
> but breaking hell knows how many existing applications is not an option.

I'm pretty sure any suid program doing path resolution and other
filesystem operations on _behalf_ of the original user will do them
with fsuid, fsgid set to the original.  Otherwise they are bound to
break in other cases too (NFS export with root_sqash, etc).

Have any counterexamples?

Thanks,
Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262414AbVDXUuQ@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262414AbVDXUuQ (ORCPT <rfc822;willy@w.ods.org>);
	Sun, 24 Apr 2005 16:50:16 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262413AbVDXUuQ
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 24 Apr 2005 16:50:16 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:35993 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S262411AbVDXUuL (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sun, 24 Apr 2005 16:50:11 -0400
To: hch@infradead.org
CC: linux-fsdevel@vger.kernel.org, hch@infradead.org,
       linux-kernel@vger.kernel.org, akpm@osdl.org
In-reply-to: <20050424201820.GA28428@infradead.org> (message from Christoph
	Hellwig on Sun, 24 Apr 2005 21:18:20 +0100)
Subject: Re: [PATCH] private mounts
References: <E1DPnOn-0000T0-00@localhost> <20050424201820.GA28428@infradead.org>
Message-Id: <E1DPo3I-0000V0-00@localhost>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Sun, 24 Apr 2005 22:50:04 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> > This simple patch adds support for private (or invisible) mounts.  The
> > rationale is to allow mounts to be private for a user but still in the
> > global namespace.
> 
> As mentioned in the last -fsdevel thread a few times the idea of per-user
> mounts is fundamentally flawed.  Crossing a namespace boundary must be
> explicit - using clone or a new unshare() syscall.

Also mentioned in that thread quite a few times is the fact the the
clone() and unshare() modell does not solve people's requirements.

Care to read through that thread and suggest an alternative solution?

Thanks,
Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262420AbVDXUyL@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262420AbVDXUyL (ORCPT <rfc822;willy@w.ods.org>);
	Sun, 24 Apr 2005 16:54:11 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262418AbVDXUyL
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 24 Apr 2005 16:54:11 -0400
Received: from parcelfarce.linux.theplanet.co.uk ([195.92.249.252]:36028 "EHLO
	parcelfarce.linux.theplanet.co.uk") by vger.kernel.org with ESMTP
	id S262417AbVDXUyJ (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sun, 24 Apr 2005 16:54:09 -0400
Date: Sun, 24 Apr 2005 21:54:22 +0100
From: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: hch@infradead.org, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk>
References: <E1DPnOn-0000T0-00@localhost> <20050424201820.GA28428@infradead.org> <E1DPo3I-0000V0-00@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1DPo3I-0000V0-00@localhost>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Sun, Apr 24, 2005 at 10:50:04PM +0200, Miklos Szeredi wrote:
> Also mentioned in that thread quite a few times is the fact the the
> clone() and unshare() modell does not solve people's requirements.

Could we please get of references to requirements without a rationale?
There's quite enough of that from Carrion-Grade Linux crowd, TYVM.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262419AbVDXVAM@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262419AbVDXVAM (ORCPT <rfc822;willy@w.ods.org>);
	Sun, 24 Apr 2005 17:00:12 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262422AbVDXVAL
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 24 Apr 2005 17:00:11 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:40857 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S262419AbVDXVAF (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sun, 24 Apr 2005 17:00:05 -0400
To: viro@parcelfarce.linux.theplanet.co.uk
CC: hch@infradead.org, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org, akpm@osdl.org
In-reply-to: <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk>
	(message from Al Viro on Sun, 24 Apr 2005 21:54:22 +0100)
Subject: Re: [PATCH] private mounts
References: <E1DPnOn-0000T0-00@localhost> <20050424201820.GA28428@infradead.org> <E1DPo3I-0000V0-00@localhost> <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk>
Message-Id: <E1DPoCg-0000W0-00@localhost>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Sun, 24 Apr 2005 22:59:46 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> > Also mentioned in that thread quite a few times is the fact the the
> > clone() and unshare() modell does not solve people's requirements.
> 
> Could we please get of references to requirements without a rationale?
> There's quite enough of that from Carrion-Grade Linux crowd, TYVM.

The rationale has been explained in that thread.  E.g. this quote from
Jamie Lokier in an answer to you:

> I believe the point is:
> 
>    1. Person is logged from client Y to server X, and mounts something on
>       $HOME/mnt/private (that's on X).
> 
>    2. On client Y, person does "scp X:mnt/private/secrets.txt ."
>       and wants it to work.
> 
> The second operation is a separate login to the first.

Solution?

Thanks,
Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262424AbVDXVGH@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262424AbVDXVGH (ORCPT <rfc822;willy@w.ods.org>);
	Sun, 24 Apr 2005 17:06:07 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262426AbVDXVGH
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 24 Apr 2005 17:06:07 -0400
Received: from parcelfarce.linux.theplanet.co.uk ([195.92.249.252]:14525 "EHLO
	parcelfarce.linux.theplanet.co.uk") by vger.kernel.org with ESMTP
	id S262422AbVDXVGD (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sun, 24 Apr 2005 17:06:03 -0400
Date: Sun, 24 Apr 2005 22:06:16 +0100
From: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: hch@infradead.org, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk>
References: <E1DPnOn-0000T0-00@localhost> <20050424201820.GA28428@infradead.org> <E1DPo3I-0000V0-00@localhost> <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk> <E1DPoCg-0000W0-00@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1DPoCg-0000W0-00@localhost>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Sun, Apr 24, 2005 at 10:59:46PM +0200, Miklos Szeredi wrote:
> > I believe the point is:
> > 
> >    1. Person is logged from client Y to server X, and mounts something on
> >       $HOME/mnt/private (that's on X).
> > 
> >    2. On client Y, person does "scp X:mnt/private/secrets.txt ."
> >       and wants it to work.
> > 
> > The second operation is a separate login to the first.
> 
> Solution?

... is the same as for the same question with "set of mounts" replaced
with "environment variables".

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262428AbVDXVGZ@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262428AbVDXVGZ (ORCPT <rfc822;willy@w.ods.org>);
	Sun, 24 Apr 2005 17:06:25 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262427AbVDXVGZ
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 24 Apr 2005 17:06:25 -0400
Received: from pentafluge.infradead.org ([213.146.154.40]:25227 "EHLO
	pentafluge.infradead.org") by vger.kernel.org with ESMTP
	id S262426AbVDXVGR (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sun, 24 Apr 2005 17:06:17 -0400
Date: Sun, 24 Apr 2005 22:06:16 +0100
From: Christoph Hellwig <hch@infradead.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: viro@parcelfarce.linux.theplanet.co.uk, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050424210616.GA29151@infradead.org>
Mail-Followup-To: Christoph Hellwig <hch@infradead.org>,
	Miklos Szeredi <miklos@szeredi.hu>,
	viro@parcelfarce.linux.theplanet.co.uk,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	akpm@osdl.org
References: <E1DPnOn-0000T0-00@localhost> <20050424201820.GA28428@infradead.org> <E1DPo3I-0000V0-00@localhost> <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk> <E1DPoCg-0000W0-00@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1DPoCg-0000W0-00@localhost>
User-Agent: Mutt/1.4.1i
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> by pentafluge.infradead.org
	See http://www.infradead.org/rpr.html
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Sun, Apr 24, 2005 at 10:59:46PM +0200, Miklos Szeredi wrote:
> > Could we please get of references to requirements without a rationale?
> > There's quite enough of that from Carrion-Grade Linux crowd, TYVM.
> 
> The rationale has been explained in that thread.  E.g. this quote from
> Jamie Lokier in an answer to you:

You still haven't written down coheren requirements.

> 
> > I believe the point is:
> > 
> >    1. Person is logged from client Y to server X, and mounts something on
> >       $HOME/mnt/private (that's on X).
> > 
> >    2. On client Y, person does "scp X:mnt/private/secrets.txt ."
> >       and wants it to work.
> > 
> > The second operation is a separate login to the first.
> 
> Solution?

just restart your shell.  Same way you do that after adjusting $PATH.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262430AbVDXVNN@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262430AbVDXVNN (ORCPT <rfc822;willy@w.ods.org>);
	Sun, 24 Apr 2005 17:13:13 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262429AbVDXVNN
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 24 Apr 2005 17:13:13 -0400
Received: from mail.shareable.org ([81.29.64.88]:3752 "EHLO mail.shareable.org")
	by vger.kernel.org with ESMTP id S262425AbVDXVNI (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sun, 24 Apr 2005 17:13:08 -0400
Date: Sun, 24 Apr 2005 22:12:49 +0100
From: Jamie Lokier <jamie@shareable.org>
To: Christoph Hellwig <hch@infradead.org>, Miklos Szeredi <miklos@szeredi.hu>,
       viro@parcelfarce.linux.theplanet.co.uk, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050424211249.GA9304@mail.shareable.org>
References: <E1DPnOn-0000T0-00@localhost> <20050424201820.GA28428@infradead.org> <E1DPo3I-0000V0-00@localhost> <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk> <E1DPoCg-0000W0-00@localhost> <20050424210616.GA29151@infradead.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050424210616.GA29151@infradead.org>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Christoph Hellwig wrote:
> > > I believe the point is:
> > > 
> > >    1. Person is logged from client Y to server X, and mounts something on
> > >       $HOME/mnt/private (that's on X).
> > > 
> > >    2. On client Y, person does "scp X:mnt/private/secrets.txt ."
> > >       and wants it to work.
> > > 
> > > The second operation is a separate login to the first.
> > 
> > Solution?
> 
> just restart your shell.  Same way you do that after adjusting $PATH.

What do you mean?

I cannot think of any way restarting the shell would solve the above.

-- Jamie

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262435AbVDXVQR@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262435AbVDXVQR (ORCPT <rfc822;willy@w.ods.org>);
	Sun, 24 Apr 2005 17:16:17 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262434AbVDXVQR
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 24 Apr 2005 17:16:17 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:48281 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S262431AbVDXVQJ (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sun, 24 Apr 2005 17:16:09 -0400
To: viro@parcelfarce.linux.theplanet.co.uk
CC: hch@infradead.org, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org, akpm@osdl.org
In-reply-to: <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk>
	(message from Al Viro on Sun, 24 Apr 2005 22:06:16 +0100)
Subject: Re: [PATCH] private mounts
References: <E1DPnOn-0000T0-00@localhost> <20050424201820.GA28428@infradead.org> <E1DPo3I-0000V0-00@localhost> <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk> <E1DPoCg-0000W0-00@localhost> <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk>
Message-Id: <E1DPoRz-0000Y0-00@localhost>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Sun, 24 Apr 2005 23:15:35 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> > > I believe the point is:
> > > 
> > >    1. Person is logged from client Y to server X, and mounts something on
> > >       $HOME/mnt/private (that's on X).
> > > 
> > >    2. On client Y, person does "scp X:mnt/private/secrets.txt ."
> > >       and wants it to work.
> > > 
> > > The second operation is a separate login to the first.
> > 
> > Solution?
> 
> ... is the same as for the same question with "set of mounts" replaced
> with "environment variables".

No.  You can't set "mount environment" in scp.

Otherwise your analogy is nice, but misses a few points.  The usage of
mounts that we are talking about is much more dynamic than usage of
environment variables.  You wouldn't want to set an environment
variable in all your shells just to access a remote system though
sshfs for example.  It _is_ possible (except the ftp, scp case) but
_very_ inconvenient.

I ask again, what solution would you suggest?

Thanks,
Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262437AbVDXVTo@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262437AbVDXVTo (ORCPT <rfc822;willy@w.ods.org>);
	Sun, 24 Apr 2005 17:19:44 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262436AbVDXVTo
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 24 Apr 2005 17:19:44 -0400
Received: from parcelfarce.linux.theplanet.co.uk ([195.92.249.252]:48833 "EHLO
	parcelfarce.linux.theplanet.co.uk") by vger.kernel.org with ESMTP
	id S262433AbVDXVT2 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sun, 24 Apr 2005 17:19:28 -0400
Date: Sun, 24 Apr 2005 22:19:42 +0100
From: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: hch@infradead.org, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050424211942.GN13052@parcelfarce.linux.theplanet.co.uk>
References: <E1DPnOn-0000T0-00@localhost> <20050424201820.GA28428@infradead.org> <E1DPo3I-0000V0-00@localhost> <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk> <E1DPoCg-0000W0-00@localhost> <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk> <E1DPoRz-0000Y0-00@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1DPoRz-0000Y0-00@localhost>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Sun, Apr 24, 2005 at 11:15:35PM +0200, Miklos Szeredi wrote:
> No.  You can't set "mount environment" in scp.

Of course you can.  It does execute the obvious set of rc files.
 
> Otherwise your analogy is nice, but misses a few points.  The usage of
> mounts that we are talking about is much more dynamic than usage of
> environment variables.

What the hell are you smoking and just how are you using shell?

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262443AbVDXV3y@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262443AbVDXV3y (ORCPT <rfc822;willy@w.ods.org>);
	Sun, 24 Apr 2005 17:29:54 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262442AbVDXV3y
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 24 Apr 2005 17:29:54 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:52889 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S262440AbVDXV3l (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sun, 24 Apr 2005 17:29:41 -0400
To: viro@parcelfarce.linux.theplanet.co.uk
CC: hch@infradead.org, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org, akpm@osdl.org
In-reply-to: <20050424211942.GN13052@parcelfarce.linux.theplanet.co.uk>
	(message from Al Viro on Sun, 24 Apr 2005 22:19:42 +0100)
Subject: Re: [PATCH] private mounts
References: <E1DPnOn-0000T0-00@localhost> <20050424201820.GA28428@infradead.org> <E1DPo3I-0000V0-00@localhost> <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk> <E1DPoCg-0000W0-00@localhost> <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk> <E1DPoRz-0000Y0-00@localhost> <20050424211942.GN13052@parcelfarce.linux.theplanet.co.uk>
Message-Id: <E1DPofK-0000Yu-00@localhost>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Sun, 24 Apr 2005 23:29:22 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> On Sun, Apr 24, 2005 at 11:15:35PM +0200, Miklos Szeredi wrote:
> > No.  You can't set "mount environment" in scp.
> 
> Of course you can.  It does execute the obvious set of rc files.

Don't think so.  ftp server and sftp server sure as hell don't.

> > Otherwise your analogy is nice, but misses a few points.  The usage of
> > mounts that we are talking about is much more dynamic than usage of
> > environment variables.
> 
> What the hell are you smoking and just how are you using shell?

Maybe differently from you :).  It's not that often that I have to
tweak environment variables.  They are usually set by scripts.

However if you write me a script that reads my mind as to which server
I want to mount with sshfs at which time, I give you all my respect.

Miklos


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262447AbVDXVio@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262447AbVDXVio (ORCPT <rfc822;willy@w.ods.org>);
	Sun, 24 Apr 2005 17:38:44 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262445AbVDXVin
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 24 Apr 2005 17:38:43 -0400
Received: from mail.shareable.org ([81.29.64.88]:5800 "EHLO mail.shareable.org")
	by vger.kernel.org with ESMTP id S262444AbVDXVig (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sun, 24 Apr 2005 17:38:36 -0400
Date: Sun, 24 Apr 2005 22:38:22 +0100
From: Jamie Lokier <jamie@shareable.org>
To: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Cc: Miklos Szeredi <miklos@szeredi.hu>, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050424213822.GB9304@mail.shareable.org>
References: <E1DPnOn-0000T0-00@localhost> <20050424201820.GA28428@infradead.org> <E1DPo3I-0000V0-00@localhost> <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk> <E1DPoCg-0000W0-00@localhost> <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Al Viro wrote:
> > > I believe the point is:
> > > 
> > >    1. Person is logged from client Y to server X, and mounts something on
> > >       $HOME/mnt/private (that's on X).
> > > 
> > >    2. On client Y, person does "scp X:mnt/private/secrets.txt ."
> > >       and wants it to work.
> > > 
> > > The second operation is a separate login to the first.
> > 
> > Solution?
> 
> ... is the same as for the same question with "set of mounts" replaced
> with "environment variables".

Not quite.

After changing environment variables in .profile, you can copy them to
other shells using ". ~/.profile".

There is no analogous mechanism to copy namespaces.

I agree with you that Miklos' patch is not the right way to do it.

Much better is the proposal to make namespaces first-class objects,
that can be switched to.  Then users can choose to have themselves a
namespace containing their private mounts, if they want it, with
login/libpam or even a program run from .profile switching into it.

While users can be allowed to create their own namespaces which affect
the path traversal of their _own_ directories, it's important that the
existence of such namespaces cannot affect path traversal of other
directories such as /etc, or /autofs/whatever - and that creation of
namespaces by a user cannot prevent the unmounting of a non-user
filesystem either.

The way to do that is shared subtrees, or something along those lines.

Here is one possible implementation:

As far as I can tell, namespaces are equivalent to predicates attached
to every mount - the predicate being "this mount intercepts path
traversal at this point if current namespace == X".

It makes sense, when users can create namespaces for themselves, that
the predicate be changed to "this mount valid if [list of current
namespace and all parent namespaces] contains X".  Parent namespace
means the namespace from which a CLONE_NS namespace inherits.

Then it would be safe (i.e. secure) to allow ordinary users to use
CLONE_NS for the purpose of establishing private namespace(s), within
which they can mount things on directories they own.  But those users
would continue to see mounts & unmounts done by the system in other
directories such as /mnt and /autofs.  Effectively this confines the
new namespace to only affecting directories owned by the user.

That would work properly with suid programs, properly with autofs and
also manual system-wide administration, and it is general enough that
it doesn't force any particular policy.  Also, it would be usable for
partial sharing of resources in virtual server and chroot scenarios.
What's not to like? :)

-- Jamie

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262448AbVDXVkM@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262448AbVDXVkM (ORCPT <rfc822;willy@w.ods.org>);
	Sun, 24 Apr 2005 17:40:12 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262446AbVDXVkM
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 24 Apr 2005 17:40:12 -0400
Received: from mail.shareable.org ([81.29.64.88]:7336 "EHLO mail.shareable.org")
	by vger.kernel.org with ESMTP id S262445AbVDXVkA (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sun, 24 Apr 2005 17:40:00 -0400
Date: Sun, 24 Apr 2005 22:39:49 +0100
From: Jamie Lokier <jamie@shareable.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: viro@parcelfarce.linux.theplanet.co.uk, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050424213949.GC9304@mail.shareable.org>
References: <E1DPnOn-0000T0-00@localhost> <20050424201820.GA28428@infradead.org> <E1DPo3I-0000V0-00@localhost> <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk> <E1DPoCg-0000W0-00@localhost> <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk> <E1DPoRz-0000Y0-00@localhost> <20050424211942.GN13052@parcelfarce.linux.theplanet.co.uk> <E1DPofK-0000Yu-00@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1DPofK-0000Yu-00@localhost>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Miklos Szeredi wrote:
> > On Sun, Apr 24, 2005 at 11:15:35PM +0200, Miklos Szeredi wrote:
> > > No.  You can't set "mount environment" in scp.
> > 
> > Of course you can.  It does execute the obvious set of rc files.
> 
> Don't think so.  ftp server and sftp server sure as hell don't.

That's no argument, because you are free to change the ftp and sftp
servers to add this behaviour if you want it.

-- Jamie

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262452AbVDXVnv@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262452AbVDXVnv (ORCPT <rfc822;willy@w.ods.org>);
	Sun, 24 Apr 2005 17:43:51 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262450AbVDXVnu
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 24 Apr 2005 17:43:50 -0400
Received: from mail.shareable.org ([81.29.64.88]:8872 "EHLO mail.shareable.org")
	by vger.kernel.org with ESMTP id S262449AbVDXVnr (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sun, 24 Apr 2005 17:43:47 -0400
Date: Sun, 24 Apr 2005 22:43:39 +0100
From: Jamie Lokier <jamie@shareable.org>
To: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Cc: Miklos Szeredi <miklos@szeredi.hu>, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050424214339.GD9304@mail.shareable.org>
References: <E1DPnOn-0000T0-00@localhost> <20050424201820.GA28428@infradead.org> <E1DPo3I-0000V0-00@localhost> <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk> <E1DPoCg-0000W0-00@localhost> <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk> <E1DPoRz-0000Y0-00@localhost> <20050424211942.GN13052@parcelfarce.linux.theplanet.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050424211942.GN13052@parcelfarce.linux.theplanet.co.uk>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Al Viro wrote:
> On Sun, Apr 24, 2005 at 11:15:35PM +0200, Miklos Szeredi wrote:
> > No.  You can't set "mount environment" in scp.
> 
> Of course you can.  It does execute the obvious set of rc files.

It doesn't work for the specified use-scenario.  The reason is that
there is no command or system call that can be executed from those rc
files to join an existing namespace.

He wants to do this:

   1. From client, login to server and do a usermount on $HOME/private.

   2. From client, login to server and read the files previously mounted.

-- Jamie

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262458AbVDXWGe@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262458AbVDXWGe (ORCPT <rfc822;willy@w.ods.org>);
	Sun, 24 Apr 2005 18:06:34 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262459AbVDXWGe
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 24 Apr 2005 18:06:34 -0400
Received: from router.student.pw.edu.pl ([194.29.137.75]:42658 "EHLO
	router.student.pw.edu.pl") by vger.kernel.org with ESMTP
	id S262458AbVDXWGb (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sun, 24 Apr 2005 18:06:31 -0400
Message-ID: <426C185C.1050204@genesilico.pl>
Date: Mon, 25 Apr 2005 00:06:20 +0200
From: maciek <maciek@genesilico.pl>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: pl, en-us, en
MIME-Version: 1.0
To: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] private mounts
References: <E1DPnOn-0000T0-00@localhost> <20050424201820.GA28428@infradead.org> <E1DPo3I-0000V0-00@localhost> <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk> <E1DPoCg-0000W0-00@localhost> <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk> <E1DPoRz-0000Y0-00@localhost> <20050424211942.GN13052@parcelfarce.linux.theplanet.co.uk> <20050424214339.GD9304@mail.shareable.org>
In-Reply-To: <20050424214339.GD9304@mail.shareable.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Hi, Jamie Lokier napisaĆ(a):

>Al Viro wrote:
>  
>
>>On Sun, Apr 24, 2005 at 11:15:35PM +0200, Miklos Szeredi wrote:
>>    
>>
>>>No.  You can't set "mount environment" in scp.
>>>      
>>>
>>Of course you can.  It does execute the obvious set of rc files.
>>    
>>
>
>It doesn't work for the specified use-scenario.  The reason is that
>there is no command or system call that can be executed from those rc
>files to join an existing namespace.
>
>He wants to do this:
>
>   1. From client, login to server and do a usermount on $HOME/private.
>
>   2. From client, login to server and read the files previously mounted.
>
>-- Jamie
>  
>
Maybe, pam_mount would be the solution?

http://www.flyn.org/projects/pam_mount/

it provides mounting a filesystem when logging in, and unmounting on
exit, just set the mount options.

Maciek Stopa



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262460AbVDXWUa@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262460AbVDXWUa (ORCPT <rfc822;willy@w.ods.org>);
	Sun, 24 Apr 2005 18:20:30 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262462AbVDXWUa
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 24 Apr 2005 18:20:30 -0400
Received: from e4.ny.us.ibm.com ([32.97.182.144]:17893 "EHLO e4.ny.us.ibm.com")
	by vger.kernel.org with ESMTP id S262460AbVDXWUK (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sun, 24 Apr 2005 18:20:10 -0400
Subject: Re: [PATCH] private mounts
From: Ram <linuxram@us.ibm.com>
To: Jamie Lokier <jamie@shareable.org>
Cc: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>,
       Miklos Szeredi <miklos@szeredi.hu>, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       Andrew Morton <akpm@osdl.org>
In-Reply-To: <20050424213822.GB9304@mail.shareable.org>
References: <E1DPnOn-0000T0-00@localhost>
	 <20050424201820.GA28428@infradead.org> <E1DPo3I-0000V0-00@localhost>
	 <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk>
	 <E1DPoCg-0000W0-00@localhost>
	 <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk>
	 <20050424213822.GB9304@mail.shareable.org>
Content-Type: text/plain
Organization: IBM 
Message-Id: <1114381206.4480.54.camel@localhost>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 
Date: Sun, 24 Apr 2005 15:20:06 -0700
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Sun, 2005-04-24 at 14:38, Jamie Lokier wrote:
> Al Viro wrote:
> > > > I believe the point is:
> > > > 
> > > >    1. Person is logged from client Y to server X, and mounts something on
> > > >       $HOME/mnt/private (that's on X).
> > > > 
> > > >    2. On client Y, person does "scp X:mnt/private/secrets.txt ."
> > > >       and wants it to work.
> > > > 
> > > > The second operation is a separate login to the first.
> > > 
> > > Solution?
> > 
> > ... is the same as for the same question with "set of mounts" replaced
> > with "environment variables".
> 
> Not quite.
> 
> After changing environment variables in .profile, you can copy them to
> other shells using ". ~/.profile".
> 
> There is no analogous mechanism to copy namespaces.
> 
> I agree with you that Miklos' patch is not the right way to do it.
> 
> Much better is the proposal to make namespaces first-class objects,
> that can be switched to.  Then users can choose to have themselves a
> namespace containing their private mounts, if they want it, with
> login/libpam or even a program run from .profile switching into it.
> 
> While users can be allowed to create their own namespaces which affect
> the path traversal of their _own_ directories, it's important that the
> existence of such namespaces cannot affect path traversal of other
> directories such as /etc, or /autofs/whatever - and that creation of
> namespaces by a user cannot prevent the unmounting of a non-user
> filesystem either.
> 
> The way to do that is shared subtrees, or something along those lines.

Right. Adding to it. To begin with the system namespace has all its
entire tree shared. So when a new namespace is cloned, the new namespace
can see any new mount/unmount/binds done in the system namespace as
well. (System namespace is the first initial namespace created by
default).

Any private mounts done by the user in his private-namespace 
will first make that part of the tree private first and then will
continue with the mount. Otherwise the private mount will end up showing
in the system namespace(since it is shared).

RP
> 
> Here is one possible implementation:
> 
> As far as I can tell, namespaces are equivalent to predicates attached
> to every mount - the predicate being "this mount intercepts path
> traversal at this point if current namespace == X".
> 
> It makes sense, when users can create namespaces for themselves, that
> the predicate be changed to "this mount valid if [list of current
> namespace and all parent namespaces] contains X".  Parent namespace
> means the namespace from which a CLONE_NS namespace inherits.
> 
> Then it would be safe (i.e. secure) to allow ordinary users to use
> CLONE_NS for the purpose of establishing private namespace(s), within
> which they can mount things on directories they own.  But those users
> would continue to see mounts & unmounts done by the system in other
> directories such as /mnt and /autofs.  Effectively this confines the
> new namespace to only affecting directories owned by the user.
> 
> That would work properly with suid programs, properly with autofs and
> also manual system-wide administration, and it is general enough that
> it doesn't force any particular policy.  Also, it would be usable for
> partial sharing of resources in virtual server and chroot scenarios.
> What's not to like? :)


> 
> -- Jamie
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262464AbVDXWXU@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262464AbVDXWXU (ORCPT <rfc822;willy@w.ods.org>);
	Sun, 24 Apr 2005 18:23:20 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262462AbVDXWXU
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 24 Apr 2005 18:23:20 -0400
Received: from mail.shareable.org ([81.29.64.88]:11432 "EHLO
	mail.shareable.org") by vger.kernel.org with ESMTP id S262461AbVDXWXN
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sun, 24 Apr 2005 18:23:13 -0400
Date: Sun, 24 Apr 2005 23:22:58 +0100
From: Jamie Lokier <jamie@shareable.org>
To: Ram <linuxram@us.ibm.com>
Cc: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>,
       Miklos Szeredi <miklos@szeredi.hu>, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH] private mounts
Message-ID: <20050424222258.GA10685@mail.shareable.org>
References: <E1DPnOn-0000T0-00@localhost> <20050424201820.GA28428@infradead.org> <E1DPo3I-0000V0-00@localhost> <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk> <E1DPoCg-0000W0-00@localhost> <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk> <20050424213822.GB9304@mail.shareable.org> <1114381206.4480.54.camel@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1114381206.4480.54.camel@localhost>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Ram wrote:
> > Much better is the proposal to make namespaces first-class objects,
> > that can be switched to.  Then users can choose to have themselves a
> > namespace containing their private mounts, if they want it, with
> > login/libpam or even a program run from .profile switching into it.
> > 
> > While users can be allowed to create their own namespaces which affect
> > the path traversal of their _own_ directories, it's important that the
> > existence of such namespaces cannot affect path traversal of other
> > directories such as /etc, or /autofs/whatever - and that creation of
> > namespaces by a user cannot prevent the unmounting of a non-user
> > filesystem either.
> > 
> > The way to do that is shared subtrees, or something along those lines.
> 
> Right. Adding to it. To begin with the system namespace has all its
> entire tree shared. So when a new namespace is cloned, the new namespace
> can see any new mount/unmount/binds done in the system namespace as
> well. (System namespace is the first initial namespace created by
> default).
> 
> Any private mounts done by the user in his private-namespace 
> will first make that part of the tree private first and then will
> continue with the mount. Otherwise the private mount will end up showing
> in the system namespace(since it is shared).

Yes, exactly that.

-- Jamie

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262542AbVDYGA7@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262542AbVDYGA7 (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 25 Apr 2005 02:00:59 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261403AbVDYGA7
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 25 Apr 2005 02:00:59 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:36250 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S262540AbVDYGAr (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 25 Apr 2005 02:00:47 -0400
To: jamie@shareable.org
CC: viro@parcelfarce.linux.theplanet.co.uk, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
In-reply-to: <20050424213822.GB9304@mail.shareable.org> (message from Jamie
	Lokier on Sun, 24 Apr 2005 22:38:22 +0100)
Subject: Re: [PATCH] private mounts
References: <E1DPnOn-0000T0-00@localhost> <20050424201820.GA28428@infradead.org> <E1DPo3I-0000V0-00@localhost> <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk> <E1DPoCg-0000W0-00@localhost> <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk> <20050424213822.GB9304@mail.shareable.org>
Message-Id: <E1DPwdo-0006xF-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Mon, 25 Apr 2005 08:00:20 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> > 
> > ... is the same as for the same question with "set of mounts" replaced
> > with "environment variables".
> 
> Not quite.
> 
> After changing environment variables in .profile, you can copy them to
> other shells using ". ~/.profile".
> 
> There is no analogous mechanism to copy namespaces.
> 
> I agree with you that Miklos' patch is not the right way to do it.

I'm not sure that it is either.  But, see bellow...

> Much better is the proposal to make namespaces first-class objects,
> that can be switched to.  Then users can choose to have themselves a
> namespace containing their private mounts, if they want it, with
> login/libpam or even a program run from .profile switching into it.

It would be good if it could be done just in libpam.  But that would
require every libpam user to call into it after the fork() or
whatever, so unshare() and join_namespace() don't mess up the server
running environment.

If not, then it would mean modifying numerous programs, having these
modifications integrated, then having distributions pick up the
changes, etc.  I would imagine quite a long cycle for this to be
acutally useful.

> While users can be allowed to create their own namespaces which affect
> the path traversal of their _own_ directories, it's important that the
> existence of such namespaces cannot affect path traversal of other
> directories such as /etc, or /autofs/whatever - and that creation of
> namespaces by a user cannot prevent the unmounting of a non-user
> filesystem either.
> 
> The way to do that is shared subtrees, or something along those lines.

Yes, but we would be achieving essentially the same as my patch, just
with more complexity.  And my patch achieves what FUSE does in 2 lines
of code, namely hide the mount from other users by returning -EACCESS
in case fsuid does not mach the mount owner.

I aggree that your solution is more flexible, but it's also hugely
more complex.  If somebody want's to implement it, fine.  But don't
expect me to do it, unless some company hires my for fs development
(hint, hint ;)

Thanks,
Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262543AbVDYGly@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262543AbVDYGly (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 25 Apr 2005 02:41:54 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262547AbVDYGly
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 25 Apr 2005 02:41:54 -0400
Received: from e1.ny.us.ibm.com ([32.97.182.141]:19936 "EHLO e1.ny.us.ibm.com")
	by vger.kernel.org with ESMTP id S262543AbVDYGlp (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 25 Apr 2005 02:41:45 -0400
Subject: Re: [PATCH] private mounts
From: Ram <linuxram@us.ibm.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: jamie@shareable.org, viro@parcelfarce.linux.theplanet.co.uk,
       hch@infradead.org, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>
In-Reply-To: <E1DPwdo-0006xF-00@dorka.pomaz.szeredi.hu>
References: <E1DPnOn-0000T0-00@localhost>
	 <20050424201820.GA28428@infradead.org> <E1DPo3I-0000V0-00@localhost>
	 <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk>
	 <E1DPoCg-0000W0-00@localhost>
	 <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk>
	 <20050424213822.GB9304@mail.shareable.org>
	 <E1DPwdo-0006xF-00@dorka.pomaz.szeredi.hu>
Content-Type: text/plain
Organization: IBM 
Message-Id: <1114411302.4480.70.camel@localhost>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 
Date: Sun, 24 Apr 2005 23:41:42 -0700
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Sun, 2005-04-24 at 23:00, Miklos Szeredi wrote:
> > > 
> > > ... is the same as for the same question with "set of mounts" replaced
> > > with "environment variables".
> > 
> > Not quite.
> > 
> > After changing environment variables in .profile, you can copy them to
> > other shells using ". ~/.profile".
> > 
> > There is no analogous mechanism to copy namespaces.
> > 
> > I agree with you that Miklos' patch is not the right way to do it.
> 
> I'm not sure that it is either.  But, see bellow...
> 
> > Much better is the proposal to make namespaces first-class objects,
> > that can be switched to.  Then users can choose to have themselves a
> > namespace containing their private mounts, if they want it, with
> > login/libpam or even a program run from .profile switching into it.
> 
> It would be good if it could be done just in libpam.  But that would
> require every libpam user to call into it after the fork() or
> whatever, so unshare() and join_namespace() don't mess up the server
> running environment.
> 
> If not, then it would mean modifying numerous programs, having these
> modifications integrated, then having distributions pick up the
> changes, etc.  I would imagine quite a long cycle for this to be
> acutally useful.
> 
> > While users can be allowed to create their own namespaces which affect
> > the path traversal of their _own_ directories, it's important that the
> > existence of such namespaces cannot affect path traversal of other
> > directories such as /etc, or /autofs/whatever - and that creation of
> > namespaces by a user cannot prevent the unmounting of a non-user
> > filesystem either.
> > 
> > The way to do that is shared subtrees, or something along those lines.
> 
> Yes, but we would be achieving essentially the same as my patch, just
> with more complexity.  And my patch achieves what FUSE does in 2 lines
> of code, namely hide the mount from other users by returning -EACCESS
> in case fsuid does not mach the mount owner.
> 

I have not yet sure how invisible mount can be used to solve the FUSE
problem.  

Again my understanding of the basic requirement of FUSE is:

1. A user being able to setup his own VFS-mount environment which
  	 is only visible to the user. 
2. The same user being able to see exactly the same VFS-mount  
	environment from any login session.

RP

> I aggree that your solution is more flexible, but it's also hugely
> more complex.  If somebody want's to implement it, fine.  But don't
> expect me to do it, unless some company hires my for fs development
> (hint, hint ;) 



> 
> Thanks,
> Miklos
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262294AbVDYHLt@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262294AbVDYHLt (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 25 Apr 2005 03:11:49 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262536AbVDYHLt
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 25 Apr 2005 03:11:49 -0400
Received: from cimice4.lam.cz ([212.71.168.94]:29088 "EHLO vagabond.light.src")
	by vger.kernel.org with ESMTP id S262294AbVDYHLn (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 25 Apr 2005 03:11:43 -0400
Date: Mon, 25 Apr 2005 09:10:47 +0200
From: Jan Hudec <bulb@ucw.cz>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: viro@parcelfarce.linux.theplanet.co.uk, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050425071047.GA13975@vagabond>
References: <E1DPnOn-0000T0-00@localhost> <20050424201820.GA28428@infradead.org> <E1DPo3I-0000V0-00@localhost> <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk> <E1DPoCg-0000W0-00@localhost> <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk> <E1DPoRz-0000Y0-00@localhost> <20050424211942.GN13052@parcelfarce.linux.theplanet.co.uk> <E1DPofK-0000Yu-00@localhost>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="x+6KMIRAuhnl3hBn"
Content-Disposition: inline
In-Reply-To: <E1DPofK-0000Yu-00@localhost>
User-Agent: Mutt/1.5.9i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org


--x+6KMIRAuhnl3hBn
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Apr 24, 2005 at 23:29:22 +0200, Miklos Szeredi wrote:
> > On Sun, Apr 24, 2005 at 11:15:35PM +0200, Miklos Szeredi wrote:
> > > No.  You can't set "mount environment" in scp.
> >=20
> > Of course you can.  It does execute the obvious set of rc files.
>=20
> Don't think so.  ftp server and sftp server sure as hell don't.

Sftp sure *DOES*. It is invoked by shell, which is not run as login one,
but even non-login shell sources an rc file.

> > > Otherwise your analogy is nice, but misses a few points.  The usage of
> > > mounts that we are talking about is much more dynamic than usage of
> > > environment variables.
> >=20
> > What the hell are you smoking and just how are you using shell?
>=20
> Maybe differently from you :).  It's not that often that I have to
> tweak environment variables.  They are usually set by scripts.
>=20
> However if you write me a script that reads my mind as to which server
> I want to mount with sshfs at which time, I give you all my respect.

I can't write a script that reads your mind. But I sure can write
a script that finds out what you mounted in the other shells (with help
of a little wrapper around the mount command).

---------------------------------------------------------------------------=
----
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

--x+6KMIRAuhnl3hBn
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCbJf3Rel1vVwhjGURAqWKAJ442/zXSBR99Mgs25QBtl1erSh5mgCeI3sg
dQSaRlVOweYNS+U9h+CDdVM=
=IZIr
-----END PGP SIGNATURE-----

--x+6KMIRAuhnl3hBn--

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262547AbVDYHPs@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262547AbVDYHPs (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 25 Apr 2005 03:15:48 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262546AbVDYHPs
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 25 Apr 2005 03:15:48 -0400
Received: from cimice4.lam.cz ([212.71.168.94]:31648 "EHLO vagabond.light.src")
	by vger.kernel.org with ESMTP id S262529AbVDYHPg (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 25 Apr 2005 03:15:36 -0400
Date: Mon, 25 Apr 2005 09:14:48 +0200
From: Jan Hudec <bulb@ucw.cz>
To: Jamie Lokier <jamie@shareable.org>
Cc: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>,
       Miklos Szeredi <miklos@szeredi.hu>, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050425071448.GB13975@vagabond>
References: <E1DPnOn-0000T0-00@localhost> <20050424201820.GA28428@infradead.org> <E1DPo3I-0000V0-00@localhost> <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk> <E1DPoCg-0000W0-00@localhost> <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk> <E1DPoRz-0000Y0-00@localhost> <20050424211942.GN13052@parcelfarce.linux.theplanet.co.uk> <20050424214339.GD9304@mail.shareable.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="neYutvxvOLaeuPCA"
Content-Disposition: inline
In-Reply-To: <20050424214339.GD9304@mail.shareable.org>
User-Agent: Mutt/1.5.9i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org


--neYutvxvOLaeuPCA
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Apr 24, 2005 at 22:43:39 +0100, Jamie Lokier wrote:
> Al Viro wrote:
> > On Sun, Apr 24, 2005 at 11:15:35PM +0200, Miklos Szeredi wrote:
> > > No.  You can't set "mount environment" in scp.
> >=20
> > Of course you can.  It does execute the obvious set of rc files.
>=20
> It doesn't work for the specified use-scenario.  The reason is that
> there is no command or system call that can be executed from those rc
> files to join an existing namespace.
>=20
> He wants to do this:
>=20
>    1. From client, login to server and do a usermount on $HOME/private.
>=20
>    2. From client, login to server and read the files previously mounted.

Ok, that almost can be done. All that is needed from kernel is an
ability to mount bind from open directory handle instead of a path! The
rest is doable in userland.

---------------------------------------------------------------------------=
----
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

--neYutvxvOLaeuPCA
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCbJjoRel1vVwhjGURAm4cAJ96DvKBIM00qtyWoro3zI7Iq+Q85QCg6Rzh
8VxNLVl5v6BAQv1I5MVRKuo=
=P0IP
-----END PGP SIGNATURE-----

--neYutvxvOLaeuPCA--

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262549AbVDYHXC@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262549AbVDYHXC (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 25 Apr 2005 03:23:02 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262553AbVDYHXB
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 25 Apr 2005 03:23:01 -0400
Received: from cimice4.lam.cz ([212.71.168.94]:35232 "EHLO vagabond.light.src")
	by vger.kernel.org with ESMTP id S262549AbVDYHWu (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 25 Apr 2005 03:22:50 -0400
Date: Mon, 25 Apr 2005 09:22:10 +0200
From: Jan Hudec <bulb@ucw.cz>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: jamie@shareable.org, viro@parcelfarce.linux.theplanet.co.uk,
       hch@infradead.org, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050425072210.GC13975@vagabond>
References: <E1DPnOn-0000T0-00@localhost> <20050424201820.GA28428@infradead.org> <E1DPo3I-0000V0-00@localhost> <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk> <E1DPoCg-0000W0-00@localhost> <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk> <20050424213822.GB9304@mail.shareable.org> <E1DPwdo-0006xF-00@dorka.pomaz.szeredi.hu>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="/e2eDi0V/xtL+Mc8"
Content-Disposition: inline
In-Reply-To: <E1DPwdo-0006xF-00@dorka.pomaz.szeredi.hu>
User-Agent: Mutt/1.5.9i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org


--/e2eDi0V/xtL+Mc8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 25, 2005 at 08:00:20 +0200, Miklos Szeredi wrote:
> > Much better is the proposal to make namespaces first-class objects,
> > that can be switched to.  Then users can choose to have themselves a
> > namespace containing their private mounts, if they want it, with
> > login/libpam or even a program run from .profile switching into it.
>=20
> It would be good if it could be done just in libpam.  But that would
> require every libpam user to call into it after the fork() or
> whatever, so unshare() and join_namespace() don't mess up the server
> running environment.

They do. The *HAVE* to do! The 'session' stage modifies the environment,
so it must be done after the fork. So if it, in addition to environment,
modifies namespace, it won't make a difference.

> If not, then it would mean modifying numerous programs, having these
> modifications integrated, then having distributions pick up the
> changes, etc.  I would imagine quite a long cycle for this to be
> acutally useful.

---------------------------------------------------------------------------=
----
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

--/e2eDi0V/xtL+Mc8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCbJqiRel1vVwhjGURAqouAJ4x/LYvTHIuIDVK7q/FUieWpxD0MgCff5oO
2DPyxtUGk5/xfKDkJp+iYG4=
=nOPf
-----END PGP SIGNATURE-----

--/e2eDi0V/xtL+Mc8--

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262565AbVDYJsO@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262565AbVDYJsO (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 25 Apr 2005 05:48:14 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262564AbVDYJsO
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 25 Apr 2005 05:48:14 -0400
Received: from dspnet.fr.eu.org ([213.186.44.138]:48402 "EHLO dspnet.fr.eu.org")
	by vger.kernel.org with ESMTP id S262563AbVDYJsJ (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 25 Apr 2005 05:48:09 -0400
Date: Mon, 25 Apr 2005 11:48:04 +0200
From: Olivier Galibert <galibert@pobox.com>
To: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050425094804.GA33040@dspnet.fr.eu.org>
Mail-Followup-To: Olivier Galibert <galibert@pobox.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
References: <E1DPnOn-0000T0-00@localhost> <20050424201820.GA28428@infradead.org> <E1DPo3I-0000V0-00@localhost> <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk> <E1DPoCg-0000W0-00@localhost> <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk> <E1DPoRz-0000Y0-00@localhost> <20050424211942.GN13052@parcelfarce.linux.theplanet.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050424211942.GN13052@parcelfarce.linux.theplanet.co.uk>
User-Agent: Mutt/1.4.2.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Sun, Apr 24, 2005 at 10:19:42PM +0100, Al Viro wrote:
> Of course you can.  It does execute the obvious set of rc files.

Is there a possibility for a process to change its namespace to
another existing one?  That would be needed to have a per-user
namespace you go to from rc files or pam.

I'd kinda wonder what happens to pwd.

  OG.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262568AbVDYJ4O@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262568AbVDYJ4O (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 25 Apr 2005 05:56:14 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262567AbVDYJ4O
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 25 Apr 2005 05:56:14 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:9883 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S262571AbVDYJ4A (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 25 Apr 2005 05:56:00 -0400
To: linuxram@us.ibm.com
CC: jamie@shareable.org, viro@parcelfarce.linux.theplanet.co.uk,
       hch@infradead.org, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org, akpm@osdl.org
In-reply-to: <1114411302.4480.70.camel@localhost> (message from Ram on Sun, 24
	Apr 2005 23:41:42 -0700)
Subject: Re: [PATCH] private mounts
References: <E1DPnOn-0000T0-00@localhost>
	 <20050424201820.GA28428@infradead.org> <E1DPo3I-0000V0-00@localhost>
	 <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk>
	 <E1DPoCg-0000W0-00@localhost>
	 <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk>
	 <20050424213822.GB9304@mail.shareable.org>
	 <E1DPwdo-0006xF-00@dorka.pomaz.szeredi.hu> <1114411302.4480.70.camel@localhost>
Message-Id: <E1DQ0JK-0007AQ-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Mon, 25 Apr 2005 11:55:26 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> I have not yet sure how invisible mount can be used to solve the FUSE
> problem.  
> 
> Again my understanding of the basic requirement of FUSE is:
> 
> 1. A user being able to setup his own VFS-mount environment which
>   	 is only visible to the user. 
> 2. The same user being able to see exactly the same VFS-mount  
> 	environment from any login session.

More generally: 

1. the files exported by the FUSE filesystem should not be accessible
   by other users.

2. The user should see exactly the same files from any login session.

These can be satisfied in various ways.  Permission checking, or by
making FUSE mounts invisible to other users, or with private
namespaces (in increasing complexity).

Thanks,
Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262576AbVDYJ7X@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262576AbVDYJ7X (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 25 Apr 2005 05:59:23 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262573AbVDYJ7W
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 25 Apr 2005 05:59:22 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:12955 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S262571AbVDYJ7R (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 25 Apr 2005 05:59:17 -0400
To: bulb@ucw.cz
CC: viro@parcelfarce.linux.theplanet.co.uk, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
In-reply-to: <20050425071047.GA13975@vagabond> (message from Jan Hudec on Mon,
	25 Apr 2005 09:10:47 +0200)
Subject: Re: [PATCH] private mounts
References: <E1DPnOn-0000T0-00@localhost> <20050424201820.GA28428@infradead.org> <E1DPo3I-0000V0-00@localhost> <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk> <E1DPoCg-0000W0-00@localhost> <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk> <E1DPoRz-0000Y0-00@localhost> <20050424211942.GN13052@parcelfarce.linux.theplanet.co.uk> <E1DPofK-0000Yu-00@localhost> <20050425071047.GA13975@vagabond>
Message-Id: <E1DQ0Mc-0007B5-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Mon, 25 Apr 2005 11:58:50 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> > Don't think so.  ftp server and sftp server sure as hell don't.
> 
> Sftp sure *DOES*. It is invoked by shell, which is not run as login one,
> but even non-login shell sources an rc file.

You win :)

> > However if you write me a script that reads my mind as to which server
> > I want to mount with sshfs at which time, I give you all my respect.
> 
> I can't write a script that reads your mind. But I sure can write
> a script that finds out what you mounted in the other shells (with help
> of a little wrapper around the mount command).

How do you bind mount it from a different namespace?  You _do_ need
bind mount, since a new mount might require password input, etc...

Thanks,
Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262572AbVDYKJM@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262572AbVDYKJM (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 25 Apr 2005 06:09:12 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262571AbVDYKJM
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 25 Apr 2005 06:09:12 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:15515 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S262569AbVDYKJJ (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 25 Apr 2005 06:09:09 -0400
To: bulb@ucw.cz
CC: jamie@shareable.org, viro@parcelfarce.linux.theplanet.co.uk,
       hch@infradead.org, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org, akpm@osdl.org
In-reply-to: <20050425072210.GC13975@vagabond> (message from Jan Hudec on Mon,
	25 Apr 2005 09:22:10 +0200)
Subject: Re: [PATCH] private mounts
References: <E1DPnOn-0000T0-00@localhost> <20050424201820.GA28428@infradead.org> <E1DPo3I-0000V0-00@localhost> <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk> <E1DPoCg-0000W0-00@localhost> <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk> <20050424213822.GB9304@mail.shareable.org> <E1DPwdo-0006xF-00@dorka.pomaz.szeredi.hu> <20050425072210.GC13975@vagabond>
Message-Id: <E1DQ0W9-0007Bu-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Mon, 25 Apr 2005 12:08:41 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> They do. The *HAVE* to do! The 'session' stage modifies the environment,
> so it must be done after the fork. So if it, in addition to environment,
> modifies namespace, it won't make a difference.

That is good news.

So in theory it's doable.  Anyone willing to help putting it all
together?

Thanks,
Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262579AbVDYKtT@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262579AbVDYKtT (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 25 Apr 2005 06:49:19 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262580AbVDYKtT
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 25 Apr 2005 06:49:19 -0400
Received: from modeemi.modeemi.cs.tut.fi ([130.230.72.134]:42457 "EHLO
	modeemi.modeemi.cs.tut.fi") by vger.kernel.org with ESMTP
	id S262579AbVDYKtR (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 25 Apr 2005 06:49:17 -0400
Date: Mon, 25 Apr 2005 13:49:15 +0300 (EEST)
From: Heikki Orsila <shd@modeemi.cs.tut.fi>
To: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] private mounts
Message-ID: <Pine.OSF.4.58.0504251344500.262468@fanta.modeemi.cs.tut.fi>
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 <miklos@szeredi.hu> wrote:
> More generally:
>
> 1. the files exported by the FUSE filesystem should not be accessible
> by other users.

Not even by root. If an admin of a remote system runs a backup script, one
does not want private home computer files go with that. The admin of the
remote system does definitely not want to make backups of my home files.

Heikki Orsila			Barbie's law:
heikki.orsila@iki.fi		"Math is hard, let's go shopping!"
http://www.iki.fi/shd

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262597AbVDYLrJ@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262597AbVDYLrJ (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 25 Apr 2005 07:47:09 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262600AbVDYLrJ
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 25 Apr 2005 07:47:09 -0400
Received: from cimice4.lam.cz ([212.71.168.94]:45474 "EHLO vagabond.light.src")
	by vger.kernel.org with ESMTP id S262597AbVDYLqm (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 25 Apr 2005 07:46:42 -0400
Date: Mon, 25 Apr 2005 13:45:50 +0200
From: Jan Hudec <bulb@ucw.cz>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: viro@parcelfarce.linux.theplanet.co.uk, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050425114550.GA25885@vagabond>
References: <20050424201820.GA28428@infradead.org> <E1DPo3I-0000V0-00@localhost> <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk> <E1DPoCg-0000W0-00@localhost> <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk> <E1DPoRz-0000Y0-00@localhost> <20050424211942.GN13052@parcelfarce.linux.theplanet.co.uk> <E1DPofK-0000Yu-00@localhost> <20050425071047.GA13975@vagabond> <E1DQ0Mc-0007B5-00@dorka.pomaz.szeredi.hu>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM"
Content-Disposition: inline
In-Reply-To: <E1DQ0Mc-0007B5-00@dorka.pomaz.szeredi.hu>
User-Agent: Mutt/1.5.9i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org


--yrj/dFKFPuw6o+aM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 25, 2005 at 11:58:50 +0200, Miklos Szeredi wrote:
> > > However if you write me a script that reads my mind as to which server
> > > I want to mount with sshfs at which time, I give you all my respect.
> >=20
> > I can't write a script that reads your mind. But I sure can write
> > a script that finds out what you mounted in the other shells (with help
> > of a little wrapper around the mount command).
>=20
> How do you bind mount it from a different namespace?  You _do_ need
> bind mount, since a new mount might require password input, etc...

Yes, I would need one thing from kernel. That one thing would be to
mount bind a directory handle, instead of path.

And if you wonder how I get the handle, that's what SCM_RIGHTS message
of unix-domain sockets is for.

---------------------------------------------------------------------------=
----
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

--yrj/dFKFPuw6o+aM
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCbNhuRel1vVwhjGURAhFnAJ9t73kcnjcUVf5osTJNRtCWASnviACgxUjz
MyxR53CrArhVzOOLbJiT11o=
=ACcW
-----END PGP SIGNATURE-----

--yrj/dFKFPuw6o+aM--

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262646AbVDYPij@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262646AbVDYPij (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 25 Apr 2005 11:38:39 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262645AbVDYPhx
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 25 Apr 2005 11:37:53 -0400
Received: from mail-in-09.arcor-online.net ([151.189.21.49]:37269 "EHLO
	mail-in-09.arcor-online.net") by vger.kernel.org with ESMTP
	id S262664AbVDYPSo (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 25 Apr 2005 11:18:44 -0400
From: "Bodo Eggert <harvested.in.lkml@posting.7eggert.dyndns.org>" 
	<7eggert@gmx.de>
Subject: Re: [PATCH] private mounts
To: Jan Hudec <bulb@ucw.cz>, Miklos Szeredi <miklos@szeredi.hu>,
       viro@parcelfarce.linux.theplanet.co.uk, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Reply-To: 7eggert@gmx.de
Date: Mon, 25 Apr 2005 17:17:35 +0200
References: <3WVU1-2GE-7@gated-at.bofh.it> <3WWn1-2ZC-5@gated-at.bofh.it> <3WWn1-2ZC-3@gated-at.bofh.it> <3WWwR-3hT-35@gated-at.bofh.it> <3WWwU-3hT-49@gated-at.bofh.it> <3WWGj-3nm-3@gated-at.bofh.it> <3WWQ9-3uA-15@gated-at.bofh.it> <3WWZG-3AC-7@gated-at.bofh.it> <3X630-2qD-21@gated-at.bofh.it> <3X8HA-4IH-15@gated-at.bofh.it> <3Xagd-5Wb-1@gated-at.bofh.it>
User-Agent: KNode/0.7.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
Message-Id: <E1DQ5LA-0003ZR-SM@be1.7eggert.dyndns.org>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Jan Hudec <bulb@ucw.cz> wrote:
> On Mon, Apr 25, 2005 at 11:58:50 +0200, Miklos Szeredi wrote:

>> How do you bind mount it from a different namespace?  You _do_ need
>> bind mount, since a new mount might require password input, etc...
> 
> Yes, I would need one thing from kernel. That one thing would be to
> mount bind a directory handle, instead of path.
> 
> And if you wonder how I get the handle, that's what SCM_RIGHTS message
> of unix-domain sockets is for.

You'll need something to get the FD from. What will that be if the mount
was done from a subshell of the midnight commander run in a screen session?

What about X sessions? Open a xterm, do the mount and then do what to get
the mount working for the programs run from the window manager?
Relogin? The xterm with the mount will be gone.
Use a daemon to keep an additional reference to the namespace? That's UGLY.

With attachable namespaces, the whole thing should be as simple as
(pseudocode)
mknamespace -p users/$UID # (like mkdir -p)
setnamespace users/$UID   # (like cd)

Optionally, the namespaces and their private mounts might be scheduled to
be removed if the last user is gone, or they need to be persistent,
depending on the applicaton (e.g. ssh used as rexec or shared mounts).
-- 
Remember, a retreating enemy is probably just falling back and regrouping. 


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262657AbVDYPwv@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262657AbVDYPwv (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 25 Apr 2005 11:52:51 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262636AbVDYPwD
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 25 Apr 2005 11:52:03 -0400
Received: from gprs189-60.eurotel.cz ([160.218.189.60]:2483 "EHLO amd.ucw.cz")
	by vger.kernel.org with ESMTP id S262653AbVDYPjU (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 25 Apr 2005 11:39:20 -0400
Date: Mon, 25 Apr 2005 17:20:50 +0200
From: Pavel Machek <pavel@ucw.cz>
To: Jamie Lokier <jamie@shareable.org>
Cc: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>,
       Miklos Szeredi <miklos@szeredi.hu>, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050425152049.GB2508@elf.ucw.cz>
References: <E1DPnOn-0000T0-00@localhost> <20050424201820.GA28428@infradead.org> <E1DPo3I-0000V0-00@localhost> <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk> <E1DPoCg-0000W0-00@localhost> <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk> <20050424213822.GB9304@mail.shareable.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050424213822.GB9304@mail.shareable.org>
X-Warning: Reading this can be dangerous to your mental health.
User-Agent: Mutt/1.5.6+20040907i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Hi!

> > > > I believe the point is:
> > > > 
> > > >    1. Person is logged from client Y to server X, and mounts something on
> > > >       $HOME/mnt/private (that's on X).
> > > > 
> > > >    2. On client Y, person does "scp X:mnt/private/secrets.txt ."
> > > >       and wants it to work.
> > > > 
> > > > The second operation is a separate login to the first.
> > > 
> > > Solution?
> > 
> > ... is the same as for the same question with "set of mounts" replaced
> > with "environment variables".
> 
> Not quite.
> 
> After changing environment variables in .profile, you can copy them to
> other shells using ". ~/.profile".
> 
> There is no analogous mechanism to copy namespaces.

Actually, after you add right mount xyzzy /foo lines into .profile,
you can just . ~/.profile ;-).
								Pavel

-- 
Boycott Kodak -- for their patent abuse against Java.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262643AbVDYQY7@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262643AbVDYQY7 (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 25 Apr 2005 12:24:59 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262668AbVDYQXs
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 25 Apr 2005 12:23:48 -0400
Received: from e32.co.us.ibm.com ([32.97.110.130]:20187 "EHLO
	e32.co.us.ibm.com") by vger.kernel.org with ESMTP id S262661AbVDYQSs
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 25 Apr 2005 12:18:48 -0400
Subject: Re: [PATCH] private mounts
From: Ram <linuxram@us.ibm.com>
To: 7eggert@gmx.de
Cc: Jan Hudec <bulb@ucw.cz>, Miklos Szeredi <miklos@szeredi.hu>,
       viro@parcelfarce.linux.theplanet.co.uk, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       Andrew Morton <akpm@osdl.org>
In-Reply-To: <E1DQ5LA-0003ZR-SM@be1.7eggert.dyndns.org>
References: <3WVU1-2GE-7@gated-at.bofh.it> <3WWn1-2ZC-5@gated-at.bofh.it>
	 <3WWn1-2ZC-3@gated-at.bofh.it> <3WWwR-3hT-35@gated-at.bofh.it>
	 <3WWwU-3hT-49@gated-at.bofh.it> <3WWGj-3nm-3@gated-at.bofh.it>
	 <3WWQ9-3uA-15@gated-at.bofh.it> <3WWZG-3AC-7@gated-at.bofh.it>
	 <3X630-2qD-21@gated-at.bofh.it> <3X8HA-4IH-15@gated-at.bofh.it>
	 <3Xagd-5Wb-1@gated-at.bofh.it>  <E1DQ5LA-0003ZR-SM@be1.7eggert.dyndns.org>
Content-Type: text/plain
Organization: IBM 
Message-Id: <1114445923.4480.94.camel@localhost>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 
Date: Mon, 25 Apr 2005 09:18:43 -0700
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, 2005-04-25 at 08:17, Bodo Eggert  wrote:
> Jan Hudec <bulb@ucw.cz> wrote:
> > On Mon, Apr 25, 2005 at 11:58:50 +0200, Miklos Szeredi wrote:
> 
> >> How do you bind mount it from a different namespace?  You _do_ need
> >> bind mount, since a new mount might require password input, etc...
> > 
> > Yes, I would need one thing from kernel. That one thing would be to
> > mount bind a directory handle, instead of path.
> > 
> > And if you wonder how I get the handle, that's what SCM_RIGHTS message
> > of unix-domain sockets is for.
> 
> You'll need something to get the FD from. What will that be if the mount
> was done from a subshell of the midnight commander run in a screen session?
> 
> What about X sessions? Open a xterm, do the mount and then do what to get
> the mount working for the programs run from the window manager?
> Relogin? The xterm with the mount will be gone.
> Use a daemon to keep an additional reference to the namespace? That's UGLY.
> 
> With attachable namespaces, the whole thing should be as simple as
> (pseudocode)
> mknamespace -p users/$UID # (like mkdir -p)
> setnamespace users/$UID   # (like cd)
> 
> Optionally, the namespaces and their private mounts might be scheduled to
> be removed if the last user is gone, or they need to be persistent,
> depending on the applicaton (e.g. ssh used as rexec or shared mounts).

Agreed.

I guess for this thread to make any progress, we need a set of coherent
requirements from FUSE team.

RP



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262690AbVDYQkQ@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262690AbVDYQkQ (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 25 Apr 2005 12:40:16 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262670AbVDYQiT
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 25 Apr 2005 12:38:19 -0400
Received: from hockin.org ([66.35.79.110]:43940 "EHLO www.hockin.org")
	by vger.kernel.org with ESMTP id S262660AbVDYQhh (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 25 Apr 2005 12:37:37 -0400
Date: Mon, 25 Apr 2005 09:37:29 -0700
From: Tim Hockin <thockin@hockin.org>
To: Olivier Galibert <galibert@pobox.com>, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050425163729.GA26142@hockin.org>
References: <E1DPnOn-0000T0-00@localhost> <20050424201820.GA28428@infradead.org> <E1DPo3I-0000V0-00@localhost> <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk> <E1DPoCg-0000W0-00@localhost> <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk> <E1DPoRz-0000Y0-00@localhost> <20050424211942.GN13052@parcelfarce.linux.theplanet.co.uk> <20050425094804.GA33040@dspnet.fr.eu.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050425094804.GA33040@dspnet.fr.eu.org>
User-Agent: Mutt/1.4.2i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Apr 25, 2005 at 11:48:04AM +0200, Olivier Galibert wrote:
> Is there a possibility for a process to change its namespace to
> another existing one?  That would be needed to have a per-user
> namespace you go to from rc files or pam.

I haven't looked at this in about a year, but as of a year ago, no.
Namespaces are/were second-class objects that exist only as referenced by
tasks.  I played with implementing a newns PAM module.  It worked, but was
full of holes.  I started writing a paper on it, but never got around to
finishing it, for various reasons.

Tim

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262733AbVDYTBI@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262733AbVDYTBI (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 25 Apr 2005 15:01:08 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262727AbVDYTBH
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 25 Apr 2005 15:01:07 -0400
Received: from e2.ny.us.ibm.com ([32.97.182.142]:14243 "EHLO e2.ny.us.ibm.com")
	by vger.kernel.org with ESMTP id S261468AbVDYTBF (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 25 Apr 2005 15:01:05 -0400
In-Reply-To: <E1DQ5LA-0003ZR-SM@be1.7eggert.dyndns.org>
To: 7eggert@gmx.de
Cc: akpm@osdl.org, Jan Hudec <bulb@ucw.cz>, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       Miklos Szeredi <miklos@szeredi.hu>,
       viro@parcelfarce.linux.theplanet.co.uk
MIME-Version: 1.0
Subject: Re: [PATCH] private mounts
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OF9C5A2A1D.78873E27-ON88256FEE.00683441-88256FEE.00688DC9@us.ibm.com>
From: Bryan Henderson <hbryan@us.ibm.com>
Date: Mon, 25 Apr 2005 12:02:43 -0700
X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Build V70_M4_01112005 Beta 3|January
 11, 2005) at 04/25/2005 15:01:00,
	Serialize complete at 04/25/2005 15:01:00
Content-Type: text/plain; charset="US-ASCII"
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

>mknamespace -p users/$UID # (like mkdir -p)
>setnamespace users/$UID   # (like cd)
       ^^^^^^^^

You realize that 'cd' is a shell command, and has to be, I hope.  That 
little fact has thrown a wrench into many of the ideas in this thread.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262738AbVDYTDn@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262738AbVDYTDn (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 25 Apr 2005 15:03:43 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262736AbVDYTDn
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 25 Apr 2005 15:03:43 -0400
Received: from mail.shareable.org ([81.29.64.88]:41128 "EHLO
	mail.shareable.org") by vger.kernel.org with ESMTP id S262729AbVDYTDk
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 25 Apr 2005 15:03:40 -0400
Date: Mon, 25 Apr 2005 20:03:15 +0100
From: Jamie Lokier <jamie@shareable.org>
To: "Bodo Eggert <harvested.in.lkml@posting.7eggert.dyndns.org>" 
	<7eggert@gmx.de>
Cc: Jan Hudec <bulb@ucw.cz>, Miklos Szeredi <miklos@szeredi.hu>,
       viro@parcelfarce.linux.theplanet.co.uk, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050425190315.GA28294@mail.shareable.org>
References: <3WWn1-2ZC-3@gated-at.bofh.it> <3WWwR-3hT-35@gated-at.bofh.it> <3WWwU-3hT-49@gated-at.bofh.it> <3WWGj-3nm-3@gated-at.bofh.it> <3WWQ9-3uA-15@gated-at.bofh.it> <3WWZG-3AC-7@gated-at.bofh.it> <3X630-2qD-21@gated-at.bofh.it> <3X8HA-4IH-15@gated-at.bofh.it> <3Xagd-5Wb-1@gated-at.bofh.it> <E1DQ5LA-0003ZR-SM@be1.7eggert.dyndns.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1DQ5LA-0003ZR-SM@be1.7eggert.dyndns.org>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Bodo Eggert <harvested.in.lkml@posting.7eggert.dyndns.org> wrote:
> Use a daemon to keep an additional reference to the namespace? That's UGLY.

Why not?  There's a daemon already: the FUSE daemon.  It's an ideal
candidate for passing out the information about the mounts it's
involved in.

-- Jamie

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262761AbVDYTKH@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262761AbVDYTKH (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 25 Apr 2005 15:10:07 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262754AbVDYTJM
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 25 Apr 2005 15:09:12 -0400
Received: from mail.shareable.org ([81.29.64.88]:42920 "EHLO
	mail.shareable.org") by vger.kernel.org with ESMTP id S262747AbVDYTHm
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 25 Apr 2005 15:07:42 -0400
Date: Mon, 25 Apr 2005 20:07:34 +0100
From: Jamie Lokier <jamie@shareable.org>
To: Pavel Machek <pavel@ucw.cz>
Cc: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>,
       Miklos Szeredi <miklos@szeredi.hu>, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050425190734.GB28294@mail.shareable.org>
References: <E1DPnOn-0000T0-00@localhost> <20050424201820.GA28428@infradead.org> <E1DPo3I-0000V0-00@localhost> <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk> <E1DPoCg-0000W0-00@localhost> <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk> <20050424213822.GB9304@mail.shareable.org> <20050425152049.GB2508@elf.ucw.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050425152049.GB2508@elf.ucw.cz>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Pavel Machek wrote:
> > > ... is the same as for the same question with "set of mounts" replaced
> > > with "environment variables".
> > 
> > Not quite.
> > 
> > After changing environment variables in .profile, you can copy them to
> > other shells using ". ~/.profile".
> > 
> > There is no analogous mechanism to copy namespaces.
> 
> Actually, after you add right mount xyzzy /foo lines into .profile,
> you can just . ~/.profile ;-).

Is there a mount command that can do that?  We're talking about
private mounts - invisible to other namespaces, which includes the
other shells.

If there was a /proc/NNN/namespace, that would do the trick :)

-- Jamie

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262747AbVDYTSC@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262747AbVDYTSC (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 25 Apr 2005 15:18:02 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261737AbVDYTPu
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 25 Apr 2005 15:15:50 -0400
Received: from mail.shareable.org ([81.29.64.88]:45224 "EHLO
	mail.shareable.org") by vger.kernel.org with ESMTP id S262747AbVDYTKu
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 25 Apr 2005 15:10:50 -0400
Date: Mon, 25 Apr 2005 20:10:15 +0100
From: Jamie Lokier <jamie@shareable.org>
To: Ram <linuxram@us.ibm.com>
Cc: 7eggert@gmx.de, Jan Hudec <bulb@ucw.cz>,
       Miklos Szeredi <miklos@szeredi.hu>,
       viro@parcelfarce.linux.theplanet.co.uk, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH] private mounts
Message-ID: <20050425191015.GC28294@mail.shareable.org>
References: <3WWwR-3hT-35@gated-at.bofh.it> <3WWwU-3hT-49@gated-at.bofh.it> <3WWGj-3nm-3@gated-at.bofh.it> <3WWQ9-3uA-15@gated-at.bofh.it> <3WWZG-3AC-7@gated-at.bofh.it> <3X630-2qD-21@gated-at.bofh.it> <3X8HA-4IH-15@gated-at.bofh.it> <3Xagd-5Wb-1@gated-at.bofh.it> <E1DQ5LA-0003ZR-SM@be1.7eggert.dyndns.org> <1114445923.4480.94.camel@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1114445923.4480.94.camel@localhost>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Ram wrote:
> I guess for this thread to make any progress, we need a set of coherent
> requirements from FUSE team.

Yes.  A list of use-cases from the FUSE team which would be nice 
to use would be a good start.  Then people who aren't so close to FUSE
can suggest alternative ways of doing those, until we whittle down to
the essential features that aren't already available in the kernel, if
any.

-- Jamie

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261197AbVDYVIx@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261197AbVDYVIx (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 25 Apr 2005 17:08:53 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261201AbVDYVIx
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 25 Apr 2005 17:08:53 -0400
Received: from e3.ny.us.ibm.com ([32.97.182.143]:18327 "EHLO e3.ny.us.ibm.com")
	by vger.kernel.org with ESMTP id S261197AbVDYVIE (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 25 Apr 2005 17:08:04 -0400
In-Reply-To: <20050424211942.GN13052@parcelfarce.linux.theplanet.co.uk>
To: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Cc: akpm@osdl.org, hch@infradead.org, linux-fsdevel@vger.kernel.org,
       linux-fsdevel-owner@vger.kernel.org, linux-kernel@vger.kernel.org,
       Miklos Szeredi <miklos@szeredi.hu>
MIME-Version: 1.0
Subject: Re: [PATCH] private mounts
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OF32F95BBA.F38B2D1F-ON88256FEE.006FE841-88256FEE.00742E46@us.ibm.com>
From: Bryan Henderson <hbryan@us.ibm.com>
Date: Mon, 25 Apr 2005 14:09:43 -0700
X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Build V70_M4_01112005 Beta 3|January
 11, 2005) at 04/25/2005 17:08:00,
	Serialize complete at 04/25/2005 17:08:00
Content-Type: text/plain; charset="US-ASCII"
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

>> No.  You can't set "mount environment" in scp.
>
>Of course you can.  It does execute the obvious set of rc files.

Incidentally, there is no obvious set of files.  The only relevant one 
that gets executed does so by accident because of a side effect of an ugly 
hack.

Jamie pointed out that such files wouldn't really help anyway, because 
there isn't a shell command that can affect the mounts seen by the copy 
server process it forks.  And others have noted that some such remote 
processes don't run shells at all.  But in case anyone is thinking of 
shell rc files as an architectural solution to the scp problem, let me 
explain shell rc files, in particular Bash's:

.profile runs when a login shell starts, which is supposed to be when you 
start a work session with the computer.  You put stuff in there like an 
announcement of mail, displaying reminders, reading news, etc.

/etc/profile is the same, but for everyone.

.bashrc runs when an interactive shell starts that isn't a login shell, 
which is supposed to be as in opening  a new shell window.  You put stuff 
in there to customize your interactive experience -- key binding, screen 
colors, aliases, and the like.

Some builds of Bash have a system level version of this as 
/etc/bash.bashrc.

All of these are for shells that are being used by a human.  They can 
really mess up a "user" that is a machine.  The most important case of a 
non-human user is a shell script.

The rc file named by the BASH_ENV environment variable runs for every 
shell, interactive or not.  But this is hard to use for personalization 
because you need a place to personalize BASH_ENV.  It's also hard to use 
for anything else, because so many programs (including some Ssh daemons) 
cut off environment variable inheritance.

Now for the ugly hack:  An interactive shell is normally one whose 
Standard Input is a terminal.  But when rsh came about, Standard Input was 
a socket, even though the shell session was quite interactive.  So Bash 
contains code that looks at several conditions consistent with an rsh 
session and if it determines that it is probably being run as the backend 
of an rsh session, it treats the shell as interactive.  Openssh 'ssh' 
doesn't need this hack, because Sshd uses a pseudo-terminal instead of a 
socket as the shell's Standard Input.  But Openssh's 'scp' falls into the 
trap and gets taken as an interactive human user of the shell.  So .bashrc 
runs.  Many are the scp sessions I've tortured with my .bashrc, and spent 
hours debugging.  (I finally removed the hack from Bash and regained 
sanity).

A design for user-specific namespaces that relies on this particular hack 
would not be clean.

On the other hand, it is possible to customize any scp backend session 
just by making a personal wrapper for the scp backend program.  The 
wrapper can do the setup -- either directly or by running an "scprc" file. 
 With Openssh, you can choose the backend program in various places.

--
Bryan Henderson                          IBM Almaden Research Center
San Jose CA                              Filesystems

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261401AbVDZI7I@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261401AbVDZI7I (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 26 Apr 2005 04:59:08 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261408AbVDZI7I
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 26 Apr 2005 04:59:08 -0400
Received: from cimice4.lam.cz ([212.71.168.94]:43433 "EHLO vagabond.light.src")
	by vger.kernel.org with ESMTP id S261401AbVDZI7B (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2005 04:59:01 -0400
Date: Tue, 26 Apr 2005 10:58:18 +0200
From: Jan Hudec <bulb@ucw.cz>
To: Bryan Henderson <hbryan@us.ibm.com>
Cc: 7eggert@gmx.de, akpm@osdl.org, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       Miklos Szeredi <miklos@szeredi.hu>,
       viro@parcelfarce.linux.theplanet.co.uk
Subject: Re: [PATCH] private mounts
Message-ID: <20050426085817.GA9131@vagabond>
References: <E1DQ5LA-0003ZR-SM@be1.7eggert.dyndns.org> <OF9C5A2A1D.78873E27-ON88256FEE.00683441-88256FEE.00688DC9@us.ibm.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG"
Content-Disposition: inline
In-Reply-To: <OF9C5A2A1D.78873E27-ON88256FEE.00683441-88256FEE.00688DC9@us.ibm.com>
User-Agent: Mutt/1.5.9i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org


--OgqxwSJOaUobr8KG
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 25, 2005 at 12:02:43 -0700, Bryan Henderson wrote:
> >mknamespace -p users/$UID # (like mkdir -p)
> >setnamespace users/$UID   # (like cd)
>        ^^^^^^^^
>=20
> You realize that 'cd' is a shell command, and has to be, I hope.  That=20
> little fact has thrown a wrench into many of the ideas in this thread.

You don't want to have such command, really! What you want is a PAM
module, that looks whether there is already a session for that user and
switches to it's namespace, if it does. Remember that it's namespace
- it can be first created, then attached and then populated with mounts.

---------------------------------------------------------------------------=
----
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

--OgqxwSJOaUobr8KG
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCbgKpRel1vVwhjGURAvcCAJ9uTr5iy8uvbR1xwY0a7xMC/Qv51wCfVRsm
QVgUu6PUrJCwZDYQ1YLvkjQ=
=519K
-----END PGP SIGNATURE-----

--OgqxwSJOaUobr8KG--

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261406AbVDZJGi@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261406AbVDZJGi (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 26 Apr 2005 05:06:38 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261407AbVDZJGi
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 26 Apr 2005 05:06:38 -0400
Received: from cimice4.lam.cz ([212.71.168.94]:47273 "EHLO vagabond.light.src")
	by vger.kernel.org with ESMTP id S261406AbVDZJGb (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2005 05:06:31 -0400
Date: Tue, 26 Apr 2005 11:05:39 +0200
From: Jan Hudec <bulb@ucw.cz>
To: "Bodo Eggert <harvested.in.lkml@posting.7eggert.dyndns.org>" 
	<7eggert@gmx.de>
Cc: Miklos Szeredi <miklos@szeredi.hu>, viro@parcelfarce.linux.theplanet.co.uk,
       hch@infradead.org, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050426090539.GB9131@vagabond>
References: <3WWn1-2ZC-3@gated-at.bofh.it> <3WWwR-3hT-35@gated-at.bofh.it> <3WWwU-3hT-49@gated-at.bofh.it> <3WWGj-3nm-3@gated-at.bofh.it> <3WWQ9-3uA-15@gated-at.bofh.it> <3WWZG-3AC-7@gated-at.bofh.it> <3X630-2qD-21@gated-at.bofh.it> <3X8HA-4IH-15@gated-at.bofh.it> <3Xagd-5Wb-1@gated-at.bofh.it> <E1DQ5LA-0003ZR-SM@be1.7eggert.dyndns.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="jho1yZJdad60DJr+"
Content-Disposition: inline
In-Reply-To: <E1DQ5LA-0003ZR-SM@be1.7eggert.dyndns.org>
User-Agent: Mutt/1.5.9i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org


--jho1yZJdad60DJr+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Apr 25, 2005 at 17:17:35 +0200, Bodo Eggert <harvested.in.lkml@posting.7eggert.dyndns.org> wrote:
> Jan Hudec <bulb@ucw.cz> wrote:
> > On Mon, Apr 25, 2005 at 11:58:50 +0200, Miklos Szeredi wrote:
> Use a daemon to keep an additional reference to the namespace? That's UGLY.

It's as ugly as ssh-agent.

But I have to say, that I really like attachable namespaces bettern than
descriptor mount bind. It's a hell lot simpler to work with.

> With attachable namespaces, the whole thing should be as simple as
> (pseudocode)
> mknamespace -p users/$UID # (like mkdir -p)
> setnamespace users/$UID   # (like cd)

Well, yes and no. We should probably just have a syscall
int join_namespace(pid_t pid)
which would join the namespace process pid uses. And then have a PAM
session module, that would attach the namespace of the first user's
session (creating new namespace if this is the first session).

> Optionally, the namespaces and their private mounts might be scheduled to
> be removed if the last user is gone, or they need to be persistent,
> depending on the applicaton (e.g. ssh used as rexec or shared mounts).

I'd have them garbage-collected. When last process using them goes away,
so does the namespace. If that's not what you want, start a persistent
process for the user.

-------------------------------------------------------------------------------
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

--jho1yZJdad60DJr+
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCbgRjRel1vVwhjGURAvjVAJ4gxvVwupwfSc957O2plamX5ezalgCbBXPj
aSZBZScuwiTy5swOcQQKnc8=
=NMIP
-----END PGP SIGNATURE-----

--jho1yZJdad60DJr+--

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261421AbVDZJR7@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261421AbVDZJR7 (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 26 Apr 2005 05:17:59 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261418AbVDZJRt
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 26 Apr 2005 05:17:49 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:19871 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S261417AbVDZJR3 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2005 05:17:29 -0400
To: jamie@shareable.org
CC: linuxram@us.ibm.com, 7eggert@gmx.de, bulb@ucw.cz,
       viro@parcelfarce.linux.theplanet.co.uk, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
In-reply-to: <20050425191015.GC28294@mail.shareable.org> (message from Jamie
	Lokier on Mon, 25 Apr 2005 20:10:15 +0100)
Subject: Re: [PATCH] private mounts
References: <3WWwR-3hT-35@gated-at.bofh.it> <3WWwU-3hT-49@gated-at.bofh.it> <3WWGj-3nm-3@gated-at.bofh.it> <3WWQ9-3uA-15@gated-at.bofh.it> <3WWZG-3AC-7@gated-at.bofh.it> <3X630-2qD-21@gated-at.bofh.it> <3X8HA-4IH-15@gated-at.bofh.it> <3Xagd-5Wb-1@gated-at.bofh.it> <E1DQ5LA-0003ZR-SM@be1.7eggert.dyndns.org> <1114445923.4480.94.camel@localhost> <20050425191015.GC28294@mail.shareable.org>
Message-Id: <E1DQMB0-00008a-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Tue, 26 Apr 2005 11:16:18 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> > I guess for this thread to make any progress, we need a set of coherent
> > requirements from FUSE team.
> 
> Yes.  A list of use-cases from the FUSE team which would be nice 
> to use would be a good start.

What kind of usecases would you like to see?  FUSE filesystems are
used just like any other filesystem, so listing "copy file from x to
z" and suchlike seems pointless ;)

> Then people who aren't so close to FUSE can suggest alternative ways
> of doing those, until we whittle down to the essential features that
> aren't already available in the kernel, if any.

The most important difference between orinary filesystems and FUSE is
the fact, that the filesystem data/metadata is provided by a userspace
process run with the privileges of the mount "owner" instead of the
kernel, or some remote entity usually running with elevated
privileges.

The security implication of this is that a non-privileged user must
not be able to use this capability to compromise the system.  Obvious
requirements arising from this are:

 - mount owner should not be able to get elevated privileges with the
   help of the mounted filesystem

 - mount owner should not be able to induce undesired behavior in
   other users' or the super user's processes

 - mount owner should not get illegitimate access to information from
   other users' and the super user's processes

These are currently ensured with the following constraints:

 1) mount is only allowed to directory or file which the mount owner
   can modify without limitation (write access + no sticky bit for
   directories)

 2) nosuid,nodev mount options are forced

 3) any process running with fsuid different from the owner is denied
    all access to the filesystem

1) and 2) are ensured by the "fusermount" mount utility which is a
   setuid root application doing the actual mount operation.

3) is ensured by a check in the permission() method in kernel

I started thinking about doing 3) in a different way because Christoph
H. made a big deal out of it, saying that FUSE is unacceptable into
mainline in this form.

The suggested use of private namespaces would be OK, but in their
current form have many limitations that make their use impractical (as
discussed in this thread).

Suggested improvements that would address these limitations:

  - implement shared subtrees

  - allow a process to join an existing namespace (make namespaces
    first-class objects)

  - implement the namespace creation/joining in a PAM module

With all that in place the check of owner against current->fsuid may
be removed from the FUSE kernel module, without compromising the
security requirements. 

Suid programs still interesting questions, since they get access even
to the private namespace causing some information leak (exact
order/timing of filesystem operations performed), giving some
ptrace-like capabilities to unprivileged users.  BTW this problem is
not strictly limited to the namespace approach, since suid programs
setting fsuid and accessing users' files will succeed with the current
approach too.

Is this information enough for further progress to be made?

Thanks for the help,
Miklos


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261422AbVDZJUw@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261422AbVDZJUw (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 26 Apr 2005 05:20:52 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261432AbVDZJUw
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 26 Apr 2005 05:20:52 -0400
Received: from pentafluge.infradead.org ([213.146.154.40]:32175 "EHLO
	pentafluge.infradead.org") by vger.kernel.org with ESMTP
	id S261422AbVDZJTk (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2005 05:19:40 -0400
Date: Tue, 26 Apr 2005 10:19:21 +0100
From: Christoph Hellwig <hch@infradead.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: jamie@shareable.org, linuxram@us.ibm.com, 7eggert@gmx.de, bulb@ucw.cz,
       viro@parcelfarce.linux.theplanet.co.uk, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050426091921.GA29810@infradead.org>
Mail-Followup-To: Christoph Hellwig <hch@infradead.org>,
	Miklos Szeredi <miklos@szeredi.hu>, jamie@shareable.org,
	linuxram@us.ibm.com, 7eggert@gmx.de, bulb@ucw.cz,
	viro@parcelfarce.linux.theplanet.co.uk,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	akpm@osdl.org
References: <3WWGj-3nm-3@gated-at.bofh.it> <3WWQ9-3uA-15@gated-at.bofh.it> <3WWZG-3AC-7@gated-at.bofh.it> <3X630-2qD-21@gated-at.bofh.it> <3X8HA-4IH-15@gated-at.bofh.it> <3Xagd-5Wb-1@gated-at.bofh.it> <E1DQ5LA-0003ZR-SM@be1.7eggert.dyndns.org> <1114445923.4480.94.camel@localhost> <20050425191015.GC28294@mail.shareable.org> <E1DQMB0-00008a-00@dorka.pomaz.szeredi.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1DQMB0-00008a-00@dorka.pomaz.szeredi.hu>
User-Agent: Mutt/1.4.1i
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> by pentafluge.infradead.org
	See http://www.infradead.org/rpr.html
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Apr 26, 2005 at 11:16:18AM +0200, Miklos Szeredi wrote:
> The most important difference between orinary filesystems and FUSE is
> the fact, that the filesystem data/metadata is provided by a userspace
> process run with the privileges of the mount "owner" instead of the
> kernel, or some remote entity usually running with elevated
> privileges.

define "mount owner".  Right now mount requires CAP_SYS_ADMIN which means
fairly privilegued.  Having some kind of user mounts would be nice, but
needs a fair amount of auditing first.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261423AbVDZJWj@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261423AbVDZJWj (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 26 Apr 2005 05:22:39 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261425AbVDZJWi
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 26 Apr 2005 05:22:38 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:24735 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S261418AbVDZJWc (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2005 05:22:32 -0400
To: hch@infradead.org
CC: jamie@shareable.org, linuxram@us.ibm.com, 7eggert@gmx.de, bulb@ucw.cz,
       viro@parcelfarce.linux.theplanet.co.uk, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
In-reply-to: <20050426091921.GA29810@infradead.org> (message from Christoph
	Hellwig on Tue, 26 Apr 2005 10:19:21 +0100)
Subject: Re: [PATCH] private mounts
References: <3WWGj-3nm-3@gated-at.bofh.it> <3WWQ9-3uA-15@gated-at.bofh.it> <3WWZG-3AC-7@gated-at.bofh.it> <3X630-2qD-21@gated-at.bofh.it> <3X8HA-4IH-15@gated-at.bofh.it> <3Xagd-5Wb-1@gated-at.bofh.it> <E1DQ5LA-0003ZR-SM@be1.7eggert.dyndns.org> <1114445923.4480.94.camel@localhost> <20050425191015.GC28294@mail.shareable.org> <E1DQMB0-00008a-00@dorka.pomaz.szeredi.hu> <20050426091921.GA29810@infradead.org>
Message-Id: <E1DQMGZ-00009n-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Tue, 26 Apr 2005 11:22:03 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org


> > The most important difference between orinary filesystems and FUSE is
> > the fact, that the filesystem data/metadata is provided by a userspace
> > process run with the privileges of the mount "owner" instead of the
> > kernel, or some remote entity usually running with elevated
> > privileges.
> 
> define "mount owner".  Right now mount requires CAP_SYS_ADMIN which means
> fairly privilegued.

FUSE uses a suid root helper (as explained below).  Please read the
whole mail.

Thanks,
Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261432AbVDZJ3s@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261432AbVDZJ3s (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 26 Apr 2005 05:29:48 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261429AbVDZJ3s
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 26 Apr 2005 05:29:48 -0400
Received: from gprs189-60.eurotel.cz ([160.218.189.60]:38807 "EHLO amd.ucw.cz")
	by vger.kernel.org with ESMTP id S261427AbVDZJ3o (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2005 05:29:44 -0400
Date: Tue, 26 Apr 2005 11:29:24 +0200
From: Pavel Machek <pavel@ucw.cz>
To: Jamie Lokier <jamie@shareable.org>
Cc: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>,
       Miklos Szeredi <miklos@szeredi.hu>, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050426092924.GA4175@elf.ucw.cz>
References: <E1DPnOn-0000T0-00@localhost> <20050424201820.GA28428@infradead.org> <E1DPo3I-0000V0-00@localhost> <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk> <E1DPoCg-0000W0-00@localhost> <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk> <20050424213822.GB9304@mail.shareable.org> <20050425152049.GB2508@elf.ucw.cz> <20050425190734.GB28294@mail.shareable.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050425190734.GB28294@mail.shareable.org>
X-Warning: Reading this can be dangerous to your mental health.
User-Agent: Mutt/1.5.6+20040907i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Hi!

> > > > ... is the same as for the same question with "set of mounts" replaced
> > > > with "environment variables".
> > > 
> > > Not quite.
> > > 
> > > After changing environment variables in .profile, you can copy them to
> > > other shells using ". ~/.profile".
> > > 
> > > There is no analogous mechanism to copy namespaces.
> > 
> > Actually, after you add right mount xyzzy /foo lines into .profile,
> > you can just . ~/.profile ;-).
> 
> Is there a mount command that can do that?  We're talking about
> private mounts - invisible to other namespaces, which includes the
> other shells.
> 
> If there was a /proc/NNN/namespace, that would do the trick :)

Sounds like the solution, then. I do not think Al Viro is going to
kill you for /proc/NNN/namespace...
								Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261430AbVDZJaT@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261430AbVDZJaT (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 26 Apr 2005 05:30:19 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261435AbVDZJaM
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 26 Apr 2005 05:30:12 -0400
Received: from atrey.karlin.mff.cuni.cz ([195.113.31.123]:6095 "EHLO
	atrey.karlin.mff.cuni.cz") by vger.kernel.org with ESMTP
	id S261430AbVDZJaF (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2005 05:30:05 -0400
Date: Tue, 26 Apr 2005 11:30:01 +0200
From: Martin Mares <mj@ucw.cz>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: jamie@shareable.org, linuxram@us.ibm.com, 7eggert@gmx.de, bulb@ucw.cz,
       viro@parcelfarce.linux.theplanet.co.uk, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050426093001.GA2419@atrey.karlin.mff.cuni.cz>
References: <3WWGj-3nm-3@gated-at.bofh.it> <3WWQ9-3uA-15@gated-at.bofh.it> <3WWZG-3AC-7@gated-at.bofh.it> <3X630-2qD-21@gated-at.bofh.it> <3X8HA-4IH-15@gated-at.bofh.it> <3Xagd-5Wb-1@gated-at.bofh.it> <E1DQ5LA-0003ZR-SM@be1.7eggert.dyndns.org> <1114445923.4480.94.camel@localhost> <20050425191015.GC28294@mail.shareable.org> <E1DQMB0-00008a-00@dorka.pomaz.szeredi.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1DQMB0-00008a-00@dorka.pomaz.szeredi.hu>
User-Agent: Mutt/1.5.6+20040907i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Hello!

>  - mount owner should not get illegitimate access to information from
>    other users' and the super user's processes
[...]
>  3) any process running with fsuid different from the owner is denied
>     all access to the filesystem

This smells. Denying access to root doesn't make any sense. I agree
that it could help in some corner cases (like avoiding automated backup
from backing up user filesystems), but in the end it's going to be
an annoyance.

Per-user namespaces (set up by PAM) look as a very reasonable solution.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"A semicolon. Another line ends in the dance of camel." -- Kabir Ahuja

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261434AbVDZJgh@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261434AbVDZJgh (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 26 Apr 2005 05:36:37 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261436AbVDZJgg
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 26 Apr 2005 05:36:36 -0400
Received: from pentafluge.infradead.org ([213.146.154.40]:59823 "EHLO
	pentafluge.infradead.org") by vger.kernel.org with ESMTP
	id S261434AbVDZJge (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2005 05:36:34 -0400
Date: Tue, 26 Apr 2005 10:36:28 +0100
From: Christoph Hellwig <hch@infradead.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: hch@infradead.org, jamie@shareable.org, linuxram@us.ibm.com,
       7eggert@gmx.de, bulb@ucw.cz, viro@parcelfarce.linux.theplanet.co.uk,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050426093628.GA30208@infradead.org>
Mail-Followup-To: Christoph Hellwig <hch@infradead.org>,
	Miklos Szeredi <miklos@szeredi.hu>, jamie@shareable.org,
	linuxram@us.ibm.com, 7eggert@gmx.de, bulb@ucw.cz,
	viro@parcelfarce.linux.theplanet.co.uk,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	akpm@osdl.org
References: <3WWZG-3AC-7@gated-at.bofh.it> <3X630-2qD-21@gated-at.bofh.it> <3X8HA-4IH-15@gated-at.bofh.it> <3Xagd-5Wb-1@gated-at.bofh.it> <E1DQ5LA-0003ZR-SM@be1.7eggert.dyndns.org> <1114445923.4480.94.camel@localhost> <20050425191015.GC28294@mail.shareable.org> <E1DQMB0-00008a-00@dorka.pomaz.szeredi.hu> <20050426091921.GA29810@infradead.org> <E1DQMGZ-00009n-00@dorka.pomaz.szeredi.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1DQMGZ-00009n-00@dorka.pomaz.szeredi.hu>
User-Agent: Mutt/1.4.1i
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> by pentafluge.infradead.org
	See http://www.infradead.org/rpr.html
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Apr 26, 2005 at 11:22:03AM +0200, Miklos Szeredi wrote:
> > define "mount owner".  Right now mount requires CAP_SYS_ADMIN which means
> > fairly privilegued.
> 
> FUSE uses a suid root helper (as explained below).  Please read the
> whole mail.

In that case you're totally out of luck.  This is not a setup we want to
account for.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261436AbVDZJoo@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261436AbVDZJoo (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 26 Apr 2005 05:44:44 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261440AbVDZJo1
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 26 Apr 2005 05:44:27 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:34975 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S261439AbVDZJlk (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2005 05:41:40 -0400
To: hch@infradead.org
CC: jamie@shareable.org, linuxram@us.ibm.com, 7eggert@gmx.de, bulb@ucw.cz,
       viro@parcelfarce.linux.theplanet.co.uk, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org, akpm@osdl.org
In-reply-to: <20050426093628.GA30208@infradead.org> (message from Christoph
	Hellwig on Tue, 26 Apr 2005 10:36:28 +0100)
Subject: Re: [PATCH] private mounts
References: <3WWZG-3AC-7@gated-at.bofh.it> <3X630-2qD-21@gated-at.bofh.it> <3X8HA-4IH-15@gated-at.bofh.it> <3Xagd-5Wb-1@gated-at.bofh.it> <E1DQ5LA-0003ZR-SM@be1.7eggert.dyndns.org> <1114445923.4480.94.camel@localhost> <20050425191015.GC28294@mail.shareable.org> <E1DQMB0-00008a-00@dorka.pomaz.szeredi.hu> <20050426091921.GA29810@infradead.org> <E1DQMGZ-00009n-00@dorka.pomaz.szeredi.hu> <20050426093628.GA30208@infradead.org>
Message-Id: <E1DQMYu-0000DL-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Tue, 26 Apr 2005 11:41:00 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> > > define "mount owner".  Right now mount requires CAP_SYS_ADMIN which means
> > > fairly privilegued.
> > 
> > FUSE uses a suid root helper (as explained below).  Please read the
> > whole mail.
> 
> In that case you're totally out of luck.  This is not a setup we want to
> account for.

Christoph, you are being thickheaded, and this is not the first time.
Please go away.

Thanks,
Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261446AbVDZJwk@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261446AbVDZJwk (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 26 Apr 2005 05:52:40 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261443AbVDZJuz
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 26 Apr 2005 05:50:55 -0400
Received: from pentafluge.infradead.org ([213.146.154.40]:4784 "EHLO
	pentafluge.infradead.org") by vger.kernel.org with ESMTP
	id S261446AbVDZJrf (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2005 05:47:35 -0400
Date: Tue, 26 Apr 2005 10:47:27 +0100
From: Christoph Hellwig <hch@infradead.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: hch@infradead.org, jamie@shareable.org, linuxram@us.ibm.com,
       7eggert@gmx.de, bulb@ucw.cz, viro@parcelfarce.linux.theplanet.co.uk,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050426094727.GA30379@infradead.org>
Mail-Followup-To: Christoph Hellwig <hch@infradead.org>,
	Miklos Szeredi <miklos@szeredi.hu>, jamie@shareable.org,
	linuxram@us.ibm.com, 7eggert@gmx.de, bulb@ucw.cz,
	viro@parcelfarce.linux.theplanet.co.uk,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	akpm@osdl.org
References: <3X8HA-4IH-15@gated-at.bofh.it> <3Xagd-5Wb-1@gated-at.bofh.it> <E1DQ5LA-0003ZR-SM@be1.7eggert.dyndns.org> <1114445923.4480.94.camel@localhost> <20050425191015.GC28294@mail.shareable.org> <E1DQMB0-00008a-00@dorka.pomaz.szeredi.hu> <20050426091921.GA29810@infradead.org> <E1DQMGZ-00009n-00@dorka.pomaz.szeredi.hu> <20050426093628.GA30208@infradead.org> <E1DQMYu-0000DL-00@dorka.pomaz.szeredi.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1DQMYu-0000DL-00@dorka.pomaz.szeredi.hu>
User-Agent: Mutt/1.4.1i
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> by pentafluge.infradead.org
	See http://www.infradead.org/rpr.html
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Apr 26, 2005 at 11:41:00AM +0200, Miklos Szeredi wrote:
> Christoph, you are being thickheaded, and this is not the first time.
> Please go away.

Please stop the flaming.  You're adding the equivalent of "I've added
a suid shell, please make sure it can only affect the caller's files".

Do you really think we want to add such crap?

You're really falling into the Hans Reiser trap - if you just wanted to
add a simple userland filesystem you'd be done by now, but you're trying
to funnel new semantics in through it.  Which is by far not as easy as
adding a simple file system driver and needs a lot more though.  


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261457AbVDZJ5G@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261457AbVDZJ5G (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 26 Apr 2005 05:57:06 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261439AbVDZJ5E
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 26 Apr 2005 05:57:04 -0400
Received: from pentafluge.infradead.org ([213.146.154.40]:14256 "EHLO
	pentafluge.infradead.org") by vger.kernel.org with ESMTP
	id S261450AbVDZJ4L (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2005 05:56:11 -0400
Date: Tue, 26 Apr 2005 10:56:08 +0100
From: Christoph Hellwig <hch@infradead.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: hch@infradead.org, jamie@shareable.org, linuxram@us.ibm.com,
       7eggert@gmx.de, bulb@ucw.cz, viro@parcelfarce.linux.theplanet.co.uk,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050426095608.GA30554@infradead.org>
Mail-Followup-To: Christoph Hellwig <hch@infradead.org>,
	Miklos Szeredi <miklos@szeredi.hu>, jamie@shareable.org,
	linuxram@us.ibm.com, 7eggert@gmx.de, bulb@ucw.cz,
	viro@parcelfarce.linux.theplanet.co.uk,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	akpm@osdl.org
References: <E1DQ5LA-0003ZR-SM@be1.7eggert.dyndns.org> <1114445923.4480.94.camel@localhost> <20050425191015.GC28294@mail.shareable.org> <E1DQMB0-00008a-00@dorka.pomaz.szeredi.hu> <20050426091921.GA29810@infradead.org> <E1DQMGZ-00009n-00@dorka.pomaz.szeredi.hu> <20050426093628.GA30208@infradead.org> <E1DQMYu-0000DL-00@dorka.pomaz.szeredi.hu> <20050426094727.GA30379@infradead.org> <E1DQMkX-0000Fy-00@dorka.pomaz.szeredi.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1DQMkX-0000Fy-00@dorka.pomaz.szeredi.hu>
User-Agent: Mutt/1.4.1i
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> by pentafluge.infradead.org
	See http://www.infradead.org/rpr.html
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Apr 26, 2005 at 11:53:01AM +0200, Miklos Szeredi wrote:
> No. FUSE is not a suid shell, and it's definitely not crap.  You are
> being impolite and without a reason.  So don't be surprised if you get
> burned.

You're model for user mounts is total crap.  The rest of the fuse kernel
code is quite nice (1).

> > You're really falling into the Hans Reiser trap - if you just wanted to
> > add a simple userland filesystem you'd be done by now, but you're trying
> > to funnel new semantics in through it.  Which is by far not as easy as
> > adding a simple file system driver and needs a lot more though.  
> 
> I've started FUSE in 2001.  Did you think it was easy getting this far?

And that matters how exactly?


(1) except the rather fishy get_user_pages variant.  but I'm not expert
enough there to comment more

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261462AbVDZKBn@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261462AbVDZKBn (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 26 Apr 2005 06:01:43 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261461AbVDZKBn
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 26 Apr 2005 06:01:43 -0400
Received: from fire.osdl.org ([65.172.181.4]:32188 "EHLO smtp.osdl.org")
	by vger.kernel.org with ESMTP id S261439AbVDZKBT (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2005 06:01:19 -0400
Date: Tue, 26 Apr 2005 03:00:10 -0700
From: Andrew Morton <akpm@osdl.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: hch@infradead.org, jamie@shareable.org, linuxram@us.ibm.com,
       7eggert@gmx.de, bulb@ucw.cz, viro@parcelfarce.linux.theplanet.co.uk,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] private mounts
Message-Id: <20050426030010.63757c8c.akpm@osdl.org>
In-Reply-To: <E1DQMYu-0000DL-00@dorka.pomaz.szeredi.hu>
References: <3WWZG-3AC-7@gated-at.bofh.it>
	<3X630-2qD-21@gated-at.bofh.it>
	<3X8HA-4IH-15@gated-at.bofh.it>
	<3Xagd-5Wb-1@gated-at.bofh.it>
	<E1DQ5LA-0003ZR-SM@be1.7eggert.dyndns.org>
	<1114445923.4480.94.camel@localhost>
	<20050425191015.GC28294@mail.shareable.org>
	<E1DQMB0-00008a-00@dorka.pomaz.szeredi.hu>
	<20050426091921.GA29810@infradead.org>
	<E1DQMGZ-00009n-00@dorka.pomaz.szeredi.hu>
	<20050426093628.GA30208@infradead.org>
	<E1DQMYu-0000DL-00@dorka.pomaz.szeredi.hu>
X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-vine-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> > > > define "mount owner".  Right now mount requires CAP_SYS_ADMIN which means
>  > > > fairly privilegued.
>  > > 
>  > > FUSE uses a suid root helper (as explained below).  Please read the
>  > > whole mail.
>  > 
>  > In that case you're totally out of luck.  This is not a setup we want to
>  > account for.
> 
>  Christoph, you are being thickheaded,

Not as thick as mine!  Could someone please explain in small words what's
wrong with an suid mount helper?

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261456AbVDZKBB@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261456AbVDZKBB (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 26 Apr 2005 06:01:01 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261439AbVDZJ5d
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 26 Apr 2005 05:57:33 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:41375 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S261453AbVDZJxj (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2005 05:53:39 -0400
To: hch@infradead.org
CC: miklos@szeredi.hu, hch@infradead.org, jamie@shareable.org,
       linuxram@us.ibm.com, 7eggert@gmx.de, bulb@ucw.cz,
       viro@parcelfarce.linux.theplanet.co.uk, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org, akpm@osdl.org
In-reply-to: <20050426094727.GA30379@infradead.org> (message from Christoph
	Hellwig on Tue, 26 Apr 2005 10:47:27 +0100)
Subject: Re: [PATCH] private mounts
References: <3X8HA-4IH-15@gated-at.bofh.it> <3Xagd-5Wb-1@gated-at.bofh.it> <E1DQ5LA-0003ZR-SM@be1.7eggert.dyndns.org> <1114445923.4480.94.camel@localhost> <20050425191015.GC28294@mail.shareable.org> <E1DQMB0-00008a-00@dorka.pomaz.szeredi.hu> <20050426091921.GA29810@infradead.org> <E1DQMGZ-00009n-00@dorka.pomaz.szeredi.hu> <20050426093628.GA30208@infradead.org> <E1DQMYu-0000DL-00@dorka.pomaz.szeredi.hu> <20050426094727.GA30379@infradead.org>
Message-Id: <E1DQMkX-0000Fy-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Tue, 26 Apr 2005 11:53:01 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> > Christoph, you are being thickheaded, and this is not the first time.
> > Please go away.
> 
> Please stop the flaming.  You're adding the equivalent of "I've added
> a suid shell, please make sure it can only affect the caller's files".
> 
> Do you really think we want to add such crap?

Do you think I'd want such crap?

No. FUSE is not a suid shell, and it's definitely not crap.  You are
being impolite and without a reason.  So don't be surprised if you get
burned.

> You're really falling into the Hans Reiser trap - if you just wanted to
> add a simple userland filesystem you'd be done by now, but you're trying
> to funnel new semantics in through it.  Which is by far not as easy as
> adding a simple file system driver and needs a lot more though.  

I've started FUSE in 2001.  Did you think it was easy getting this far?

Come on!

Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261473AbVDZKFP@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261473AbVDZKFP (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 26 Apr 2005 06:05:15 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261461AbVDZKFO
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 26 Apr 2005 06:05:14 -0400
Received: from pentafluge.infradead.org ([213.146.154.40]:25008 "EHLO
	pentafluge.infradead.org") by vger.kernel.org with ESMTP
	id S261443AbVDZKCq (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2005 06:02:46 -0400
Date: Tue, 26 Apr 2005 11:02:41 +0100
From: Christoph Hellwig <hch@infradead.org>
To: Christoph Hellwig <hch@infradead.org>, Miklos Szeredi <miklos@szeredi.hu>,
       jamie@shareable.org, linuxram@us.ibm.com, 7eggert@gmx.de, bulb@ucw.cz,
       viro@parcelfarce.linux.theplanet.co.uk, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050426100241.GA30674@infradead.org>
Mail-Followup-To: Christoph Hellwig <hch@infradead.org>,
	Miklos Szeredi <miklos@szeredi.hu>, jamie@shareable.org,
	linuxram@us.ibm.com, 7eggert@gmx.de, bulb@ucw.cz,
	viro@parcelfarce.linux.theplanet.co.uk,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	akpm@osdl.org
References: <1114445923.4480.94.camel@localhost> <20050425191015.GC28294@mail.shareable.org> <E1DQMB0-00008a-00@dorka.pomaz.szeredi.hu> <20050426091921.GA29810@infradead.org> <E1DQMGZ-00009n-00@dorka.pomaz.szeredi.hu> <20050426093628.GA30208@infradead.org> <E1DQMYu-0000DL-00@dorka.pomaz.szeredi.hu> <20050426094727.GA30379@infradead.org> <E1DQMkX-0000Fy-00@dorka.pomaz.szeredi.hu> <20050426095608.GA30554@infradead.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050426095608.GA30554@infradead.org>
User-Agent: Mutt/1.4.1i
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> by pentafluge.infradead.org
	See http://www.infradead.org/rpr.html
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Apr 26, 2005 at 10:56:08AM +0100, Christoph Hellwig wrote:
> On Tue, Apr 26, 2005 at 11:53:01AM +0200, Miklos Szeredi wrote:
> > No. FUSE is not a suid shell, and it's definitely not crap.  You are
> > being impolite and without a reason.  So don't be surprised if you get
> > burned.
> 
> You're model for user mounts is total crap.  The rest of the fuse kernel
> code is quite nice (1).

And btw, in case you think this flaming here is going to bring you forward
in any way:  it's not.  User mounts and namespace-related changes don't
belong into a lowelevel filesystem driver no matter what.  Whatever way
to handle user-private mount we're going to agree on it's not going to be
inside the fuse code.  So you're really better of stoppign the flaming,
stripping out those bits and help writing down a scheme that you'd want
to see in the VFS so we can see whether it makes sense and is implementable.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261451AbVDZKIv@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261451AbVDZKIv (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 26 Apr 2005 06:08:51 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261443AbVDZKIv
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 26 Apr 2005 06:08:51 -0400
Received: from pentafluge.infradead.org ([213.146.154.40]:28848 "EHLO
	pentafluge.infradead.org") by vger.kernel.org with ESMTP
	id S261466AbVDZKEW (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2005 06:04:22 -0400
Date: Tue, 26 Apr 2005 11:04:12 +0100
From: Christoph Hellwig <hch@infradead.org>
To: Andrew Morton <akpm@osdl.org>
Cc: Miklos Szeredi <miklos@szeredi.hu>, hch@infradead.org, jamie@shareable.org,
       linuxram@us.ibm.com, 7eggert@gmx.de, bulb@ucw.cz,
       viro@parcelfarce.linux.theplanet.co.uk, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050426100412.GA30762@infradead.org>
Mail-Followup-To: Christoph Hellwig <hch@infradead.org>,
	Andrew Morton <akpm@osdl.org>, Miklos Szeredi <miklos@szeredi.hu>,
	jamie@shareable.org, linuxram@us.ibm.com, 7eggert@gmx.de,
	bulb@ucw.cz, viro@parcelfarce.linux.theplanet.co.uk,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
References: <3Xagd-5Wb-1@gated-at.bofh.it> <E1DQ5LA-0003ZR-SM@be1.7eggert.dyndns.org> <1114445923.4480.94.camel@localhost> <20050425191015.GC28294@mail.shareable.org> <E1DQMB0-00008a-00@dorka.pomaz.szeredi.hu> <20050426091921.GA29810@infradead.org> <E1DQMGZ-00009n-00@dorka.pomaz.szeredi.hu> <20050426093628.GA30208@infradead.org> <E1DQMYu-0000DL-00@dorka.pomaz.szeredi.hu> <20050426030010.63757c8c.akpm@osdl.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050426030010.63757c8c.akpm@osdl.org>
User-Agent: Mutt/1.4.1i
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> by pentafluge.infradead.org
	See http://www.infradead.org/rpr.html
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Apr 26, 2005 at 03:00:10AM -0700, Andrew Morton wrote:
> Not as thick as mine!  Could someone please explain in small words what's
> wrong with an suid mount helper?

Nothing per-se.  What makes it bad is the contect of a userland filesystem
where the actual filesystem operations in the mounted filesystem happen
in contect of a non-privilegued user.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261439AbVDZKJ1@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261439AbVDZKJ1 (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 26 Apr 2005 06:09:27 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261452AbVDZKI6
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 26 Apr 2005 06:08:58 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:47775 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S261439AbVDZKBw (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2005 06:01:52 -0400
To: hch@infradead.org
CC: miklos@szeredi.hu, hch@infradead.org, jamie@shareable.org,
       linuxram@us.ibm.com, 7eggert@gmx.de, bulb@ucw.cz,
       viro@parcelfarce.linux.theplanet.co.uk, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org, akpm@osdl.org
In-reply-to: <20050426095608.GA30554@infradead.org> (message from Christoph
	Hellwig on Tue, 26 Apr 2005 10:56:08 +0100)
Subject: Re: [PATCH] private mounts
References: <E1DQ5LA-0003ZR-SM@be1.7eggert.dyndns.org> <1114445923.4480.94.camel@localhost> <20050425191015.GC28294@mail.shareable.org> <E1DQMB0-00008a-00@dorka.pomaz.szeredi.hu> <20050426091921.GA29810@infradead.org> <E1DQMGZ-00009n-00@dorka.pomaz.szeredi.hu> <20050426093628.GA30208@infradead.org> <E1DQMYu-0000DL-00@dorka.pomaz.szeredi.hu> <20050426094727.GA30379@infradead.org> <E1DQMkX-0000Fy-00@dorka.pomaz.szeredi.hu> <20050426095608.GA30554@infradead.org>
Message-Id: <E1DQMsX-0000IX-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Tue, 26 Apr 2005 12:01:17 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> > No. FUSE is not a suid shell, and it's definitely not crap.  You are
> > being impolite and without a reason.  So don't be surprised if you get
> > burned.
> 
> You're model for user mounts is total crap.  The rest of the fuse kernel
> code is quite nice (1).

Oh, a compliment from Christoph H. himself, how flattering :)

And for the first part, please _explain_ why you think it's crap.
Calling something crap, will surely not make it less crap, will it?

Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261485AbVDZKRO@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261485AbVDZKRO (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 26 Apr 2005 06:17:14 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261483AbVDZKRL
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 26 Apr 2005 06:17:11 -0400
Received: from fire.osdl.org ([65.172.181.4]:32191 "EHLO smtp.osdl.org")
	by vger.kernel.org with ESMTP id S261443AbVDZKO6 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2005 06:14:58 -0400
Date: Tue, 26 Apr 2005 03:14:14 -0700
From: Andrew Morton <akpm@osdl.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: miklos@szeredi.hu, hch@infradead.org, jamie@shareable.org,
       linuxram@us.ibm.com, 7eggert@gmx.de, bulb@ucw.cz,
       viro@parcelfarce.linux.theplanet.co.uk, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org
Subject: Re: [PATCH] private mounts
Message-Id: <20050426031414.260568b5.akpm@osdl.org>
In-Reply-To: <20050426100412.GA30762@infradead.org>
References: <3Xagd-5Wb-1@gated-at.bofh.it>
	<E1DQ5LA-0003ZR-SM@be1.7eggert.dyndns.org>
	<1114445923.4480.94.camel@localhost>
	<20050425191015.GC28294@mail.shareable.org>
	<E1DQMB0-00008a-00@dorka.pomaz.szeredi.hu>
	<20050426091921.GA29810@infradead.org>
	<E1DQMGZ-00009n-00@dorka.pomaz.szeredi.hu>
	<20050426093628.GA30208@infradead.org>
	<E1DQMYu-0000DL-00@dorka.pomaz.szeredi.hu>
	<20050426030010.63757c8c.akpm@osdl.org>
	<20050426100412.GA30762@infradead.org>
X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-vine-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Christoph Hellwig <hch@infradead.org> wrote:
>
> On Tue, Apr 26, 2005 at 03:00:10AM -0700, Andrew Morton wrote:
> > Not as thick as mine!  Could someone please explain in small words what's
> > wrong with an suid mount helper?
> 
> Nothing per-se.  What makes it bad is the contect of a userland filesystem
> where the actual filesystem operations in the mounted filesystem happen
> in contect of a non-privilegued user.

That's one of the major points of FUSE, isn't it?  So that unprivileged
users can do interesting things.

Or are you saying that that's a desirable objective, but it should be
implemented differently?


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261460AbVDZKQy@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261460AbVDZKQy (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 26 Apr 2005 06:16:54 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261453AbVDZKNy
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 26 Apr 2005 06:13:54 -0400
Received: from pentafluge.infradead.org ([213.146.154.40]:39344 "EHLO
	pentafluge.infradead.org") by vger.kernel.org with ESMTP
	id S261443AbVDZKJ6 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2005 06:09:58 -0400
Date: Tue, 26 Apr 2005 11:09:53 +0100
From: Christoph Hellwig <hch@infradead.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: hch@infradead.org, jamie@shareable.org, linuxram@us.ibm.com,
       7eggert@gmx.de, bulb@ucw.cz, viro@parcelfarce.linux.theplanet.co.uk,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050426100953.GB30762@infradead.org>
Mail-Followup-To: Christoph Hellwig <hch@infradead.org>,
	Miklos Szeredi <miklos@szeredi.hu>, jamie@shareable.org,
	linuxram@us.ibm.com, 7eggert@gmx.de, bulb@ucw.cz,
	viro@parcelfarce.linux.theplanet.co.uk,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	akpm@osdl.org
References: <20050425191015.GC28294@mail.shareable.org> <E1DQMB0-00008a-00@dorka.pomaz.szeredi.hu> <20050426091921.GA29810@infradead.org> <E1DQMGZ-00009n-00@dorka.pomaz.szeredi.hu> <20050426093628.GA30208@infradead.org> <E1DQMYu-0000DL-00@dorka.pomaz.szeredi.hu> <20050426094727.GA30379@infradead.org> <E1DQMkX-0000Fy-00@dorka.pomaz.szeredi.hu> <20050426095608.GA30554@infradead.org> <E1DQMsX-0000IX-00@dorka.pomaz.szeredi.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1DQMsX-0000IX-00@dorka.pomaz.szeredi.hu>
User-Agent: Mutt/1.4.1i
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> by pentafluge.infradead.org
	See http://www.infradead.org/rpr.html
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Apr 26, 2005 at 12:01:17PM +0200, Miklos Szeredi wrote:
> And for the first part, please _explain_ why you think it's crap.

Problem 1:

 - you're mounting things into the global namespace, but expect it only
   be visible to a certain subset of processes.  these processes are also
   not specicified by a tradition unix session / process group / etc but
   against all the process attributes we have based on the uid

Problem 2, which is related:

 - in fuse you're re-routing filesystem request to userspace, so fine so good
 - mount is currently a privilegued operation, and expects a privilegued
   filesystem implementation, not an ordinary user
 - to bypass that you have a suid mount wrapper
 - now you need various hacks to make sure this can't be used by other users

in short you are hacking around the namespace management which sits above
the filesystems in a rather broken way.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261469AbVDZKlj@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261469AbVDZKlj (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 26 Apr 2005 06:41:39 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261482AbVDZKkr
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 26 Apr 2005 06:40:47 -0400
Received: from pentafluge.infradead.org ([213.146.154.40]:10673 "EHLO
	pentafluge.infradead.org") by vger.kernel.org with ESMTP
	id S261469AbVDZKjT (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2005 06:39:19 -0400
Date: Tue, 26 Apr 2005 11:38:59 +0100
From: Christoph Hellwig <hch@infradead.org>
To: Andrew Morton <akpm@osdl.org>
Cc: Christoph Hellwig <hch@infradead.org>, miklos@szeredi.hu,
       jamie@shareable.org, linuxram@us.ibm.com, 7eggert@gmx.de, bulb@ucw.cz,
       viro@parcelfarce.linux.theplanet.co.uk, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050426103859.GA31468@infradead.org>
Mail-Followup-To: Christoph Hellwig <hch@infradead.org>,
	Andrew Morton <akpm@osdl.org>, miklos@szeredi.hu,
	jamie@shareable.org, linuxram@us.ibm.com, 7eggert@gmx.de,
	bulb@ucw.cz, viro@parcelfarce.linux.theplanet.co.uk,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
References: <1114445923.4480.94.camel@localhost> <20050425191015.GC28294@mail.shareable.org> <E1DQMB0-00008a-00@dorka.pomaz.szeredi.hu> <20050426091921.GA29810@infradead.org> <E1DQMGZ-00009n-00@dorka.pomaz.szeredi.hu> <20050426093628.GA30208@infradead.org> <E1DQMYu-0000DL-00@dorka.pomaz.szeredi.hu> <20050426030010.63757c8c.akpm@osdl.org> <20050426100412.GA30762@infradead.org> <20050426031414.260568b5.akpm@osdl.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050426031414.260568b5.akpm@osdl.org>
User-Agent: Mutt/1.4.1i
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> by pentafluge.infradead.org
	See http://www.infradead.org/rpr.html
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Apr 26, 2005 at 03:14:14AM -0700, Andrew Morton wrote:
> That's one of the major points of FUSE, isn't it?  So that unprivileged
> users can do interesting things.
> 
> Or are you saying that that's a desirable objective, but it should be
> implemented differently?

It's a desirable objective, but the implementation is wrong.  If we have
a user mount that must be known to the VFS so that the VFS can enforce
the right restrictions instead of leaving various crude hacks in lowlevel
filesystem drivers.  Especially as fuse isn't the only filesystem for which
this makes sense - smbfs or v9fs want the same features aswell


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261407AbVDZLsA@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261407AbVDZLsA (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 26 Apr 2005 07:48:00 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261475AbVDZLr7
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 26 Apr 2005 07:47:59 -0400
Received: from mail-in-03.arcor-online.net ([151.189.21.43]:7094 "EHLO
	mail-in-03.arcor-online.net") by vger.kernel.org with ESMTP
	id S261407AbVDZLr4 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2005 07:47:56 -0400
Date: Tue, 26 Apr 2005 13:46:56 +0200 (CEST)
From: Bodo Eggert <7eggert@gmx.de>
To: Jan Hudec <bulb@ucw.cz>
Cc: "Bodo Eggert <harvested.in.lkml@posting.7eggert.dyndns.org>" 
	<7eggert@gmx.de>,
       Miklos Szeredi <miklos@szeredi.hu>,
       viro@parcelfarce.linux.theplanet.co.uk, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
In-Reply-To: <20050426090539.GB9131@vagabond>
Message-ID: <Pine.LNX.4.58.0504261339300.4555@be1.lrz>
References: <3WWn1-2ZC-3@gated-at.bofh.it> <3WWwR-3hT-35@gated-at.bofh.it>
 <3WWwU-3hT-49@gated-at.bofh.it> <3WWGj-3nm-3@gated-at.bofh.it>
 <3WWQ9-3uA-15@gated-at.bofh.it> <3WWZG-3AC-7@gated-at.bofh.it>
 <3X630-2qD-21@gated-at.bofh.it> <3X8HA-4IH-15@gated-at.bofh.it>
 <3Xagd-5Wb-1@gated-at.bofh.it> <E1DQ5LA-0003ZR-SM@be1.7eggert.dyndns.org>
 <20050426090539.GB9131@vagabond>
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

On Tue, 26 Apr 2005, Jan Hudec wrote:
> On Mon, Apr 25, 2005 at 17:17:35 +0200, Bodo Eggert <harvested.in.lkml@posting.7eggert.dyndns.org> wrote:

> > With attachable namespaces, the whole thing should be as simple as
> > (pseudocode)
> > mknamespace -p users/$UID # (like mkdir -p)
> > setnamespace users/$UID   # (like cd)
> 
> Well, yes and no. We should probably just have a syscall
> int join_namespace(pid_t pid)
> which would join the namespace process pid uses. And then have a PAM
> session module, that would attach the namespace of the first user's
> session (creating new namespace if this is the first session).

This will help for the fuse case, but since namespaces are hierarchical
(as I understand them), you can as well make the structure visible and
thereby turn a feature for one user into a feature for general use.
-- 
Programming is an art form that fights back. 

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261475AbVDZLtF@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261475AbVDZLtF (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 26 Apr 2005 07:49:05 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261472AbVDZLtF
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 26 Apr 2005 07:49:05 -0400
Received: from mail-in-01.arcor-online.net ([151.189.21.41]:5803 "EHLO
	mail-in-01.arcor-online.net") by vger.kernel.org with ESMTP
	id S261452AbVDZLs7 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2005 07:48:59 -0400
Date: Tue, 26 Apr 2005 13:48:04 +0200 (CEST)
From: Bodo Eggert <7eggert@gmx.de>
To: Bryan Henderson <hbryan@us.ibm.com>
Cc: 7eggert@gmx.de, akpm@osdl.org, Jan Hudec <bulb@ucw.cz>, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       Miklos Szeredi <miklos@szeredi.hu>,
       viro@parcelfarce.linux.theplanet.co.uk
Subject: Re: [PATCH] private mounts
In-Reply-To: <OF9C5A2A1D.78873E27-ON88256FEE.00683441-88256FEE.00688DC9@us.ibm.com>
Message-ID: <Pine.LNX.4.58.0504261347110.4555@be1.lrz>
References: <OF9C5A2A1D.78873E27-ON88256FEE.00683441-88256FEE.00688DC9@us.ibm.com>
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

On Mon, 25 Apr 2005, Bryan Henderson wrote:

> >mknamespace -p users/$UID # (like mkdir -p)
> >setnamespace users/$UID   # (like cd)
>        ^^^^^^^^
> 
> You realize that 'cd' is a shell command, and has to be, I hope.  That 
> little fact has thrown a wrench into many of the ideas in this thread.

I suppose it will be called by the login process or by wrappers like 
'nice'.
-- 
Never stand when you can sit, never sit when you can lie down, never stay
awake when you can sleep.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261488AbVDZMJB@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261488AbVDZMJB (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 26 Apr 2005 08:09:01 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261492AbVDZMJA
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 26 Apr 2005 08:09:00 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:18336 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S261488AbVDZMIt (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2005 08:08:49 -0400
To: hch@infradead.org
CC: jamie@shareable.org, linuxram@us.ibm.com, 7eggert@gmx.de, bulb@ucw.cz,
       viro@parcelfarce.linux.theplanet.co.uk, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org, akpm@osdl.org
In-reply-to: <20050426100953.GB30762@infradead.org> (message from Christoph
	Hellwig on Tue, 26 Apr 2005 11:09:53 +0100)
Subject: Re: [PATCH] private mounts
References: <20050425191015.GC28294@mail.shareable.org> <E1DQMB0-00008a-00@dorka.pomaz.szeredi.hu> <20050426091921.GA29810@infradead.org> <E1DQMGZ-00009n-00@dorka.pomaz.szeredi.hu> <20050426093628.GA30208@infradead.org> <E1DQMYu-0000DL-00@dorka.pomaz.szeredi.hu> <20050426094727.GA30379@infradead.org> <E1DQMkX-0000Fy-00@dorka.pomaz.szeredi.hu> <20050426095608.GA30554@infradead.org> <E1DQMsX-0000IX-00@dorka.pomaz.szeredi.hu> <20050426100953.GB30762@infradead.org>
Message-Id: <E1DQOrK-0000Uh-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Tue, 26 Apr 2005 14:08:10 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> Problem 1:
> 
>  - you're mounting things into the global namespace, but expect it only
>    be visible to a certain subset of processes.  these processes are also
>    not specicified by a tradition unix session / process group / etc but
>    against all the process attributes we have based on the uid

Yes, so?  You are harping on this without ever telling a concrete
technical problem with it.

Yes root will assume it's a directory that can be read.  And it will
get -EACCESS.  Is there a problem with this?  Is there a problem with
NFS exports with root_squash (which is the default btw)?  See the
similarity?

> Problem 2, which is related:
> 
>  - in fuse you're re-routing filesystem request to userspace, so fine so good
>  - mount is currently a privilegued operation, and expects a privilegued
>    filesystem implementation, not an ordinary user
>  - to bypass that you have a suid mount wrapper
>  - now you need various hacks to make sure this can't be used by other users

Why is this a hack?  What is the problem with it?

NFSv3 implements it's own permission checking based on credentials
returned by the server.  If client doesn't support Posix ACL and
server does, the permission bits _will_ be out of sync with the actual
permission you get on the file, and you will never know why.  Is it a
problem?  Can it be avoided?

How would sshfs client create permission bits for files, which match
the exact permissions that the user has on the server.  The client
doesn't even know the uid of the user on the remote system let alone
what groups it belongs to.

Think about these problems, and if you have a _solution_ that you
think is better, then pray tell me.  If you don't have a solution, but
just want to bad-mouth the current FUSE imlementation, I'm not
interested.

Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261504AbVDZNHy@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261504AbVDZNHy (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 26 Apr 2005 09:07:54 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261511AbVDZNHx
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 26 Apr 2005 09:07:53 -0400
Received: from wproxy.gmail.com ([64.233.184.205]:8371 "EHLO wproxy.gmail.com")
	by vger.kernel.org with ESMTP id S261504AbVDZNGC convert rfc822-to-8bit
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2005 09:06:02 -0400
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=BojrSMoLurtM5xpGOa0DCGVSO5LWtaXpDOyfZR8TSVcSdZvmsRdt92r09Xx7kOZIrWCrTpzISa93Vm9imvd2PjkEZfb0qrzjDmiGnEIATo+xy5QVECH3A1xsNGL7jTCSRcTbHWD9sHBpdsk4e1eCgVThDjIeWufls9LuXT73wdA=
Message-ID: <a4e6962a05042606053c1e6ba8@mail.gmail.com>
Date: Tue, 26 Apr 2005 08:05:30 -0500
From: Eric Van Hensbergen <ericvh@gmail.com>
Reply-To: Eric Van Hensbergen <ericvh@gmail.com>
To: Christoph Hellwig <hch@infradead.org>, Andrew Morton <akpm@osdl.org>,
       miklos@szeredi.hu, jamie@shareable.org, linuxram@us.ibm.com,
       7eggert@gmx.de, bulb@ucw.cz, viro@parcelfarce.linux.theplanet.co.uk,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] private mounts
In-Reply-To: <20050426103859.GA31468@infradead.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Content-Disposition: inline
References: <1114445923.4480.94.camel@localhost>
	 <E1DQMB0-00008a-00@dorka.pomaz.szeredi.hu>
	 <20050426091921.GA29810@infradead.org>
	 <E1DQMGZ-00009n-00@dorka.pomaz.szeredi.hu>
	 <20050426093628.GA30208@infradead.org>
	 <E1DQMYu-0000DL-00@dorka.pomaz.szeredi.hu>
	 <20050426030010.63757c8c.akpm@osdl.org>
	 <20050426100412.GA30762@infradead.org>
	 <20050426031414.260568b5.akpm@osdl.org>
	 <20050426103859.GA31468@infradead.org>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On 4/26/05, Christoph Hellwig <hch@infradead.org> wrote:
> On Tue, Apr 26, 2005 at 03:14:14AM -0700, Andrew Morton wrote:
> > That's one of the major points of FUSE, isn't it?  So that unprivileged
> > users can do interesting things.
> >
> > Or are you saying that that's a desirable objective, but it should be
> > implemented differently?
> 
> It's a desirable objective, but the implementation is wrong.  If we have
> a user mount that must be known to the VFS so that the VFS can enforce
> the right restrictions instead of leaving various crude hacks in lowlevel
> filesystem drivers.  Especially as fuse isn't the only filesystem for which
> this makes sense - smbfs or v9fs want the same features aswell
> 

As far as I can see, there are (at least) two distinct discussions
going on.  For the sake of clarity I'd like to get the security
concerns/requirements laid out for each:

TYPE A) general purpose user-mountable file systems

This seems to be the feature that would be useful to many of the
different file systems
(fuse, v9fs, smbfs, etc).  What security restrictions need to be in
place if we were to take the SYS_CAP_ADMIN check out of sys_mount? 
>>From what I've gleaned from the discussion so far they would include:
1) Restricting where the user could mount
- the suggestion so far is that a user could only mount/bind to a
directory he could write to and without the sticky bit
2) Restricting what the user could mount
- mounting arbitrary file systems could expose a vulnerability
3) Restricting how the user can mount (nosuid, nogid enforced)
4) Restricting user mount visibility (in private namespaces) so as not
to pollute the global namespace
5) Restricting how much the user can mount (restricting number of
mounts and/or number of namespaces with a ulimit)

(1), (3), (4), and (5) seem straightforward to me.  (2) seems a little
less-so.  I understand a little bit of the vulnerability (specifically
when mounting physical devices with file systems that may or may not
be tolerant to malicious formats), but I hate restricting the user.  I
guess perhaps we could have something in the file system type
information which describes whether or not it should be user
mountable.

Implementation wise, (3), (4), and (5) seem pretty straightforward to
implement in the kernel.  (1) and (2) wouldn't be that bad if the
policy were kept simple, but any sort of an advanced policy would seem
to require a user-space application to assist -- but that seems to
require an suid mount app.  Is it better to come up with a simple
universal policy and implement it within VFS, or allow for a more
complex policy that would require user-space application assistance?

Have I missed something from the security angle?

TYPE B) per-user namespace / attachable namespace / etc.

This argument seems to come mostly from the FUSE camp, but the goal
seems noble enough: given enforcement of requiring private namespaces
for user mounts in (A), how can we create a user-environment similar
to what the user would expect without private mounts (ie. a global
namespace per user).

The main security concern here has been stated in detail before, so
I'll only summarize: only the user who mounted the file system should
be granted access to it.  Private namespaces in (A) seem to grant that
security, however, the (B) requirement of a global user namespace
invalidates that as a new login (or su) woud attatch to the private
namespace (and if I'm not mistaken a root su'ing to the user would
also get around the currently implemented permission scheme).  I don't
think anyone has come up with a good solution here.

My hack at a solution for this (even though I don't see this as a big
requirement):
Proper namespace inheritance (meaning changes to the parent are
propagated to the child as references not copies -- I believe the
shared subtree RFC covers the right semantics) along with establishing
a new private namespace for each login session.  As far as accessing
already mounted FUSE file systems between different login sessions --
I see this as a really obscure requirement that complicates things a
great deal, however --  if you split the concept of "srv points" from
file system mounts and remount the file system (perhaps automatically
as part of initiating the session) for every new login -- then you can
revalidate security at each of these mounts.  This sounds somewhat
extreme, but with a proper keyring style authentication management
system it could be made fairly transparent to the user.  I believe
others in this thread have proposed something similar, I'm just
weighing in that if this must be a requirement (and I don't think it
should), this is how I think it should be done.

In general (TYPE A) and (TYPE B) are related but separate
implementation efforts, I think we should focus on getting (TYPE A)
right (due to the system security implications) and evolve a solution
to (TYPE B) based on use.

         -eric

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261521AbVDZNY6@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261521AbVDZNY6 (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 26 Apr 2005 09:24:58 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261518AbVDZNY5
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 26 Apr 2005 09:24:57 -0400
Received: from atrey.karlin.mff.cuni.cz ([195.113.31.123]:17383 "EHLO
	atrey.karlin.mff.cuni.cz") by vger.kernel.org with ESMTP
	id S261512AbVDZNYp (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2005 09:24:45 -0400
Date: Tue, 26 Apr 2005 15:19:44 +0200
From: Pavel Machek <pavel@ucw.cz>
To: Christoph Hellwig <hch@infradead.org>, Miklos Szeredi <miklos@szeredi.hu>,
       jamie@shareable.org, linuxram@us.ibm.com, 7eggert@gmx.de, bulb@ucw.cz,
       viro@parcelfarce.linux.theplanet.co.uk, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050426131943.GC2226@openzaurus.ucw.cz>
References: <3Xagd-5Wb-1@gated-at.bofh.it> <E1DQ5LA-0003ZR-SM@be1.7eggert.dyndns.org> <1114445923.4480.94.camel@localhost> <20050425191015.GC28294@mail.shareable.org> <E1DQMB0-00008a-00@dorka.pomaz.szeredi.hu> <20050426091921.GA29810@infradead.org> <E1DQMGZ-00009n-00@dorka.pomaz.szeredi.hu> <20050426093628.GA30208@infradead.org> <E1DQMYu-0000DL-00@dorka.pomaz.szeredi.hu> <20050426094727.GA30379@infradead.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050426094727.GA30379@infradead.org>
User-Agent: Mutt/1.3.27i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Hi!

> > Christoph, you are being thickheaded, and this is not the first time.
> > Please go away.
> 
> Please stop the flaming.  You're adding the equivalent of "I've added
...
> You're really falling into the Hans Reiser trap - if you just wanted to
> add a simple userland filesystem you'd be done by now, but you're trying
> to funnel new semantics in through it.  Which is by far not as easy as
> adding a simple file system driver and needs a lot more though.  

Could we get root-only fuse in, please? It is usefull on its own...

In many cases you can just run one fused for all the users and handle
priviledges inside fused...
				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261533AbVDZN3g@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261533AbVDZN3g (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 26 Apr 2005 09:29:36 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261514AbVDZN3Y
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 26 Apr 2005 09:29:24 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:31648 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S261487AbVDZN3V (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2005 09:29:21 -0400
To: pavel@ucw.cz
CC: hch@infradead.org, jamie@shareable.org, linuxram@us.ibm.com,
       7eggert@gmx.de, bulb@ucw.cz, viro@parcelfarce.linux.theplanet.co.uk,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
In-reply-to: <20050426131943.GC2226@openzaurus.ucw.cz> (message from Pavel
	Machek on Tue, 26 Apr 2005 15:19:44 +0200)
Subject: Re: [PATCH] private mounts
References: <3Xagd-5Wb-1@gated-at.bofh.it> <E1DQ5LA-0003ZR-SM@be1.7eggert.dyndns.org> <1114445923.4480.94.camel@localhost> <20050425191015.GC28294@mail.shareable.org> <E1DQMB0-00008a-00@dorka.pomaz.szeredi.hu> <20050426091921.GA29810@infradead.org> <E1DQMGZ-00009n-00@dorka.pomaz.szeredi.hu> <20050426093628.GA30208@infradead.org> <E1DQMYu-0000DL-00@dorka.pomaz.szeredi.hu> <20050426094727.GA30379@infradead.org> <20050426131943.GC2226@openzaurus.ucw.cz>
Message-Id: <E1DQQ73-0000Zv-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Tue, 26 Apr 2005 15:28:29 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> Could we get root-only fuse in, please?

chmod u-s /usr/bin/fusermount

Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261538AbVDZOHp@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261538AbVDZOHp (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 26 Apr 2005 10:07:45 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261532AbVDZOHp
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 26 Apr 2005 10:07:45 -0400
Received: from mail.shareable.org ([81.29.64.88]:4777 "EHLO mail.shareable.org")
	by vger.kernel.org with ESMTP id S261527AbVDZOHe (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2005 10:07:34 -0400
Date: Tue, 26 Apr 2005 15:07:15 +0100
From: Jamie Lokier <jamie@shareable.org>
To: Pavel Machek <pavel@ucw.cz>
Cc: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>,
       Miklos Szeredi <miklos@szeredi.hu>, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050426140715.GA10833@mail.shareable.org>
References: <E1DPnOn-0000T0-00@localhost> <20050424201820.GA28428@infradead.org> <E1DPo3I-0000V0-00@localhost> <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk> <E1DPoCg-0000W0-00@localhost> <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk> <20050424213822.GB9304@mail.shareable.org> <20050425152049.GB2508@elf.ucw.cz> <20050425190734.GB28294@mail.shareable.org> <20050426092924.GA4175@elf.ucw.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050426092924.GA4175@elf.ucw.cz>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Pavel Machek wrote:
> > > Actually, after you add right mount xyzzy /foo lines into .profile,
> > > you can just . ~/.profile ;-).
> > 
> > Is there a mount command that can do that?  We're talking about
> > private mounts - invisible to other namespaces, which includes the
> > other shells.
> > 
> > If there was a /proc/NNN/namespace, that would do the trick :)
> 
> Sounds like the solution, then. I do not think Al Viro is going to
> kill you for /proc/NNN/namespace...

Looking closer, I think we already have it.

It's called /proc/NNN/root.

Does chroot into /proc/NNN/root cause the chroot'ing process to adopt
the namespace of NNN?  Looking at the code, I think it does.

Furthermore, I think a daemon can acquire file descriptors for
multiple namespaces already, by open("/") and passing descriptors
between processes.  And the chroot can be done using /proc/self/fd/N
after receiving a descriptor.

This is because file descriptors, and current->fs->pwd and
current->fs->root, record the vfsmnt as well as the dentry that they
opened.

So no new system calls are needed.  A daemon to hand out per-user
namespaces (or any other policy) can be written using existing
kernels, and those namespaces can be joined using chroot.

That's the theory anyway.  It's always possible I misread the code (as
I don't use namespaces and don't have tools handy to try them).

-- Jamie

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261548AbVDZOPm@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261548AbVDZOPm (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 26 Apr 2005 10:15:42 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261544AbVDZOPm
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 26 Apr 2005 10:15:42 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:43168 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S261539AbVDZOPQ (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2005 10:15:16 -0400
To: ericvh@gmail.com
CC: hch@infradead.org, akpm@osdl.org, miklos@szeredi.hu, jamie@shareable.org,
       linuxram@us.ibm.com, 7eggert@gmx.de, bulb@ucw.cz,
       viro@parcelfarce.linux.theplanet.co.uk, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org
In-reply-to: <a4e6962a05042606053c1e6ba8@mail.gmail.com> (message from Eric
	Van Hensbergen on Tue, 26 Apr 2005 08:05:30 -0500)
Subject: Re: [PATCH] private mounts
References: <1114445923.4480.94.camel@localhost>
	 <E1DQMB0-00008a-00@dorka.pomaz.szeredi.hu>
	 <20050426091921.GA29810@infradead.org>
	 <E1DQMGZ-00009n-00@dorka.pomaz.szeredi.hu>
	 <20050426093628.GA30208@infradead.org>
	 <E1DQMYu-0000DL-00@dorka.pomaz.szeredi.hu>
	 <20050426030010.63757c8c.akpm@osdl.org>
	 <20050426100412.GA30762@infradead.org>
	 <20050426031414.260568b5.akpm@osdl.org>
	 <20050426103859.GA31468@infradead.org> <a4e6962a05042606053c1e6ba8@mail.gmail.com>
Message-Id: <E1DQQpD-0000dL-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Tue, 26 Apr 2005 16:14:07 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> TYPE A) general purpose user-mountable file systems
> 
> This seems to be the feature that would be useful to many of the
> different file systems
> (fuse, v9fs, smbfs, etc).  What security restrictions need to be in
> place if we were to take the SYS_CAP_ADMIN check out of sys_mount? 
> >From what I've gleaned from the discussion so far they would include:
> 1) Restricting where the user could mount
> - the suggestion so far is that a user could only mount/bind to a
> directory he could write to and without the sticky bit
> 2) Restricting what the user could mount
> - mounting arbitrary file systems could expose a vulnerability
> 3) Restricting how the user can mount (nosuid, nogid enforced)
> 4) Restricting user mount visibility (in private namespaces) so as not
> to pollute the global namespace
> 5) Restricting how much the user can mount (restricting number of
> mounts and/or number of namespaces with a ulimit)
> 
> (1), (3), (4), and (5) seem straightforward to me.  (2) seems a little
> less-so.  I understand a little bit of the vulnerability (specifically
> when mounting physical devices with file systems that may or may not
> be tolerant to malicious formats), but I hate restricting the user.  I
> guess perhaps we could have something in the file system type
> information which describes whether or not it should be user
> mountable.
> 
> Implementation wise, (3), (4), and (5) seem pretty straightforward to
> implement in the kernel.

Umm, yes.  Here's one I prepared earlier:

  http://marc.theaimsgroup.com/?l=linux-fsdevel&m=107701207710525&w=2

I stopped maintaining it, because as you can see getting something
accepted to mainline is not as easy as it first sounds :)

> (1) and (2) wouldn't be that bad if the policy were kept simple,
> but any sort of an advanced policy would seem to require a
> user-space application to assist -- but that seems to require an
> suid mount app.  Is it better to come up with a simple universal
> policy and implement it within VFS, or allow for a more complex
> policy that would require user-space application assistance?

Good question.  I'm undecided on the suid/nosuid mount issue.  It sure
would be nicer not to need a mount helper...

> Have I missed something from the security angle?
> 
> TYPE B) per-user namespace / attachable namespace / etc.
> 
> This argument seems to come mostly from the FUSE camp, but the goal
> seems noble enough: given enforcement of requiring private namespaces
> for user mounts in (A), how can we create a user-environment similar
> to what the user would expect without private mounts (ie. a global
> namespace per user).
> 
> The main security concern here has been stated in detail before, so
> I'll only summarize: only the user who mounted the file system should
> be granted access to it.  Private namespaces in (A) seem to grant that
> security, however, the (B) requirement of a global user namespace
> invalidates that as a new login (or su) woud attatch to the private
> namespace (and if I'm not mistaken a root su'ing to the user would
> also get around the currently implemented permission scheme).

Note: I'm mostly concerned with system security not user security.
Protecting user data from root is a treacherous thing to attempt.

> I don't think anyone has come up with a good solution here.
> 
> My hack at a solution for this (even though I don't see this as a big
> requirement):
> Proper namespace inheritance (meaning changes to the parent are
> propagated to the child as references not copies -- I believe the
> shared subtree RFC covers the right semantics) along with establishing
> a new private namespace for each login session.  As far as accessing
> already mounted FUSE file systems between different login sessions --
> I see this as a really obscure requirement

It's not that obscure.  Scp, sftp each will be a separate session, and
you can't set up mounts within an scp.

> that complicates things a great deal, however -- if you split the
> concept of "srv points" from file system mounts and remount the file
> system (perhaps automatically as part of initiating the session) for
> every new login -- then you can revalidate security at each of these
> mounts.

Why would you have to revalidate?  A simple bind mount would suffice.
However, joining another sessions namespace makes more sense, than
copying the mounts individually.

Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261546AbVDZPBt@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261546AbVDZPBt (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 26 Apr 2005 11:01:49 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261558AbVDZPBt
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 26 Apr 2005 11:01:49 -0400
Received: from wproxy.gmail.com ([64.233.184.192]:58629 "EHLO wproxy.gmail.com")
	by vger.kernel.org with ESMTP id S261546AbVDZPBp convert rfc822-to-8bit
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2005 11:01:45 -0400
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=p73oCTtbeVtc3UwmyFguO39/mGTHpn3qu7KjcCSH+saS7pedf1F6+f2ngaiRpr1gj7IjGMRYsUOABjxIr5REJL/Ua1gPGQvsbUawPjvgX87HU7ZJdo4mNkzIt86likPcgM0U+eR1KNIVhErYVOXUcdv/sVxvTJnVvPhB4YLfn9g=
Message-ID: <a4e6962a05042608013534505a@mail.gmail.com>
Date: Tue, 26 Apr 2005 10:01:45 -0500
From: Eric Van Hensbergen <ericvh@gmail.com>
Reply-To: Eric Van Hensbergen <ericvh@gmail.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Subject: Re: [PATCH] private mounts
Cc: hch@infradead.org, akpm@osdl.org, jamie@shareable.org, linuxram@us.ibm.com,
       7eggert@gmx.de, bulb@ucw.cz, viro@parcelfarce.linux.theplanet.co.uk,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <E1DQQpD-0000dL-00@dorka.pomaz.szeredi.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Content-Disposition: inline
References: <1114445923.4480.94.camel@localhost>
	 <E1DQMGZ-00009n-00@dorka.pomaz.szeredi.hu>
	 <20050426093628.GA30208@infradead.org>
	 <E1DQMYu-0000DL-00@dorka.pomaz.szeredi.hu>
	 <20050426030010.63757c8c.akpm@osdl.org>
	 <20050426100412.GA30762@infradead.org>
	 <20050426031414.260568b5.akpm@osdl.org>
	 <20050426103859.GA31468@infradead.org>
	 <a4e6962a05042606053c1e6ba8@mail.gmail.com>
	 <E1DQQpD-0000dL-00@dorka.pomaz.szeredi.hu>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On 4/26/05, Miklos Szeredi <miklos@szeredi.hu> wrote:
> > that complicates things a great deal, however -- if you split the
> > concept of "srv points" from file system mounts and remount the file
> > system (perhaps automatically as part of initiating the session) for
> > every new login -- then you can revalidate security at each of these
> > mounts.
> 
> Why would you have to revalidate?  A simple bind mount would suffice.
> However, joining another sessions namespace makes more sense, than
> copying the mounts individually.
> 

Well, the forced revalidation was an attempt to protect "user-data"
from root, which, as you pointed out in your reply, is a somewhat
sketchy thing.  It may also be useful if you wish to share a
filesystem/namespace with a subset of users with a permissions model
outside of the normal user/groups model (which the user doesn't really
have any control over).

Anyways, just an additional idea for consideration -- as I said, I
don't really feel a strong need for this, so perhaps its best
forgotten for now.

          -eric

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261657AbVDZRKk@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261657AbVDZRKk (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 26 Apr 2005 13:10:40 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261674AbVDZRKj
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 26 Apr 2005 13:10:39 -0400
Received: from e1.ny.us.ibm.com ([32.97.182.141]:35765 "EHLO e1.ny.us.ibm.com")
	by vger.kernel.org with ESMTP id S261657AbVDZRKb (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2005 13:10:31 -0400
In-Reply-To: <Pine.LNX.4.58.0504261347110.4555@be1.lrz>
To: Bodo Eggert <7eggert@gmx.de>
Cc: 7eggert@gmx.de, akpm@osdl.org, Jan Hudec <bulb@ucw.cz>, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       Miklos Szeredi <miklos@szeredi.hu>,
       viro@parcelfarce.linux.theplanet.co.uk
MIME-Version: 1.0
Subject: Re: [PATCH] private mounts
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OF7E89A8B8.2AC04C42-ON88256FEF.005DACE1-88256FEF.005E7421@us.ibm.com>
From: Bryan Henderson <hbryan@us.ibm.com>
Date: Tue, 26 Apr 2005 10:10:22 -0700
X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Build V70_M4_01112005 Beta 3|January
 11, 2005) at 04/26/2005 13:10:29,
	Serialize complete at 04/26/2005 13:10:29
Content-Type: text/plain; charset="US-ASCII"
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

>> >mknamespace -p users/$UID # (like mkdir -p)
>> >setnamespace users/$UID   # (like cd)
>>                               ^^^^^^^^
>> 
>> You realize that 'cd' is a shell command, and has to be, I hope.  That 
>> little fact has thrown a wrench into many of the ideas in this thread.
>
>I suppose it will be called by the login process or by wrappers like 
>'nice'.

Just to be clear, then: this idea is fundamentally different from the 
mkdir/cd analogy the thread starts with above.  And it misses one rather 
important requirement compared to mkdir/cd:  You can't add a new mount to 
an existing shell.

Several more complicated schemes that may achieve that are being discussed 
in this thread.

--
Bryan Henderson                          IBM Almaden Research Center
San Jose CA                              Filesystems


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261731AbVDZSzp@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261731AbVDZSzp (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 26 Apr 2005 14:55:45 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261726AbVDZSzp
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 26 Apr 2005 14:55:45 -0400
Received: from e6.ny.us.ibm.com ([32.97.182.146]:28045 "EHLO e6.ny.us.ibm.com")
	by vger.kernel.org with ESMTP id S261713AbVDZSzf (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2005 14:55:35 -0400
In-Reply-To: <20050426100412.GA30762@infradead.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: 7eggert@gmx.de, Andrew Morton <akpm@osdl.org>, bulb@ucw.cz,
       hch@infradead.org, jamie@shareable.org, linux-fsdevel@vger.kernel.org,
       linux-fsdevel-owner@vger.kernel.org, linux-kernel@vger.kernel.org,
       linuxram@us.ibm.com, Miklos Szeredi <miklos@szeredi.hu>,
       viro@parcelfarce.linux.theplanet.co.uk
MIME-Version: 1.0
Subject: Re: [PATCH] private mounts
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OF1B93E71A.E3220FB2-ON88256FEF.005F16B8-88256FEF.00681383@us.ibm.com>
From: Bryan Henderson <hbryan@us.ibm.com>
Date: Tue, 26 Apr 2005 11:55:28 -0700
X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Build V70_M4_01112005 Beta 3|January
 11, 2005) at 04/26/2005 14:55:32,
	Serialize complete at 04/26/2005 14:55:32
Content-Type: text/plain; charset="US-ASCII"
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

>On Tue, Apr 26, 2005 at 03:00:10AM -0700, Andrew Morton wrote:
>> Not as thick as mine!  Could someone please explain in small words 
what's
>> wrong with an suid mount helper?
>
>Nothing per-se.  What makes it bad is the context of a userland 
filesystem
>where the actual filesystem operations in the mounted filesystem happen
>in context of a non-privileged user.

How did the fact that the file access system calls involve user-controlled 
code come into this?  I thought the FUSE kernel code already shielded the 
system from said code to everyone's satisfaction.

We've been talking, rather, about the namespace changes.  The exact same 
issue exists with a non-userspace filesystem where the user controls the 
filesystem contents.  For example, a filesystem on a user-supplied CD.  A 
system administrator -- personally or through his setuid proxy -- might 
want to mount this CD for the benefit of some users/processes/whatever but 
not add it to the global namespace.

The issue of private mounts (mount = namespace change) would be good to 
resolve separately from any problem with bringing user space code into the 
kernel.

BTW, since Miklos said "mount helper" and others have said "mount 
wrapper," I think some of us may not be familiar with mount helpers.  It's 
irrelevant to this discussion, but: util-linux 'mount' has a little-known 
feature wherein it can run a filesystem-type-specific program in a child 
process to do some of the mount function.  A "mount wrapper" would be the 
opposite -- a filesystem-type-specific program that runs the generic 
'mount' program in a child process.

--
Bryan Henderson                          IBM Almaden Research Center
San Jose CA                              Filesystems

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261775AbVDZUJx@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261775AbVDZUJx (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 26 Apr 2005 16:09:53 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261772AbVDZUJf
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 26 Apr 2005 16:09:35 -0400
Received: from mail-in-05.arcor-online.net ([151.189.21.45]:45272 "EHLO
	mail-in-05.arcor-online.net") by vger.kernel.org with ESMTP
	id S261767AbVDZUJT (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2005 16:09:19 -0400
Date: Tue, 26 Apr 2005 22:08:15 +0200 (CEST)
From: Bodo Eggert <7eggert@gmx.de>
To: Bryan Henderson <hbryan@us.ibm.com>
Cc: Bodo Eggert <7eggert@gmx.de>, akpm@osdl.org, Jan Hudec <bulb@ucw.cz>,
       hch@infradead.org, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org, Miklos Szeredi <miklos@szeredi.hu>,
       viro@parcelfarce.linux.theplanet.co.uk
Subject: Re: [PATCH] private mounts
In-Reply-To: <OF7E89A8B8.2AC04C42-ON88256FEF.005DACE1-88256FEF.005E7421@us.ibm.com>
Message-ID: <Pine.LNX.4.58.0504262031490.3393@be1.lrz>
References: <OF7E89A8B8.2AC04C42-ON88256FEF.005DACE1-88256FEF.005E7421@us.ibm.com>
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

On Tue, 26 Apr 2005, Bryan Henderson wrote:

> >> >mknamespace -p users/$UID # (like mkdir -p)
> >> >setnamespace users/$UID   # (like cd)
> >>                               ^^^^^^^^
> >> 
> >> You realize that 'cd' is a shell command, and has to be, I hope.  That 
> >> little fact has thrown a wrench into many of the ideas in this thread.
> >
> >I suppose it will be called by the login process or by wrappers like 
> >'nice'.
> 
> Just to be clear, then: this idea is fundamentally different from the 
> mkdir/cd analogy the thread starts with above.

NACK, it's very similar to the cd "$HOME" (or ulimit calls) done by the
login mechanism, except for the fact that no shell does implement a
setnamespace command and therefore can't leave that namespace. If the
shell were actually modified to implement setnamespace, that command would
be exactly like the cd command.

The wrapper I mentioned will usurally not be needed for normal operation,
but if users want additional private namespaces, they'll need this
seperate wrapper (or to modify the application or the shell) in order to
switch into them.

>  And it misses one rather 
> important requirement compared to mkdir/cd:  You can't add a new mount to 
> an existing shell.

The mount would be a part of the current namespace, which is shared across
all current user processes unless they are started without login (e.g.
procmail[0]) or running in a different namespace (the user called
setnamespace).



[0] If you want procmail in a user namespace, use a wrapper like
---/usr/bin/procmail---
#!/bin/sh
exec /usr/bin/setnamespace /users/"$UID" -- /usr/bin/procmail.bin "$@"
---

BTW: I think the namespaces will need the normal file permissions.

-- 
Fun things to slip into your budget
Paradigm pro-activator (a whole pack)
	(you mean beer?)

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261495AbVDZUQ5@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261495AbVDZUQ5 (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 26 Apr 2005 16:16:57 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261774AbVDZUOv
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 26 Apr 2005 16:14:51 -0400
Received: from gprs189-60.eurotel.cz ([160.218.189.60]:43438 "EHLO amd.ucw.cz")
	by vger.kernel.org with ESMTP id S261772AbVDZUOf (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2005 16:14:35 -0400
Date: Tue, 26 Apr 2005 22:14:11 +0200
From: Pavel Machek <pavel@ucw.cz>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: hch@infradead.org, jamie@shareable.org, linuxram@us.ibm.com,
       7eggert@gmx.de, bulb@ucw.cz, viro@parcelfarce.linux.theplanet.co.uk,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050426201411.GA20109@elf.ucw.cz>
References: <1114445923.4480.94.camel@localhost> <20050425191015.GC28294@mail.shareable.org> <E1DQMB0-00008a-00@dorka.pomaz.szeredi.hu> <20050426091921.GA29810@infradead.org> <E1DQMGZ-00009n-00@dorka.pomaz.szeredi.hu> <20050426093628.GA30208@infradead.org> <E1DQMYu-0000DL-00@dorka.pomaz.szeredi.hu> <20050426094727.GA30379@infradead.org> <20050426131943.GC2226@openzaurus.ucw.cz> <E1DQQ73-0000Zv-00@dorka.pomaz.szeredi.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1DQQ73-0000Zv-00@dorka.pomaz.szeredi.hu>
X-Warning: Reading this can be dangerous to your mental health.
User-Agent: Mutt/1.5.6+20040907i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Hi!

> > Could we get root-only fuse in, please?
> 
> chmod u-s /usr/bin/fusermount

:-)))). I meant merging patches that are not controversial into
mainline. AFAICT only controversial pieces are "make it safe for
non-root users"...

							Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261816AbVDZWIa@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261816AbVDZWIa (ORCPT <rfc822;willy@w.ods.org>);
	Tue, 26 Apr 2005 18:08:30 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261815AbVDZWIa
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 26 Apr 2005 18:08:30 -0400
Received: from e2.ny.us.ibm.com ([32.97.182.142]:61352 "EHLO e2.ny.us.ibm.com")
	by vger.kernel.org with ESMTP id S261808AbVDZWIJ (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2005 18:08:09 -0400
In-Reply-To: <Pine.LNX.4.58.0504262031490.3393@be1.lrz>
To: Bodo Eggert <7eggert@gmx.de>
Cc: Bodo Eggert <7eggert@gmx.de>, akpm@osdl.org, Jan Hudec <bulb@ucw.cz>,
       hch@infradead.org, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org, Miklos Szeredi <miklos@szeredi.hu>,
       viro@parcelfarce.linux.theplanet.co.uk
MIME-Version: 1.0
Subject: Re: [PATCH] private mounts
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OFF84C9B1E.2214C52C-ON88256FEF.007799F7-88256FEF.0079B32B@us.ibm.com>
From: Bryan Henderson <hbryan@us.ibm.com>
Date: Tue, 26 Apr 2005 15:07:58 -0700
X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Build V70_M4_01112005 Beta 3|January
 11, 2005) at 04/26/2005 18:08:05,
	Serialize complete at 04/26/2005 18:08:05
Content-Type: text/plain; charset="US-ASCII"
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

>> Just to be clear, then: this idea is fundamentally different from the 
>> mkdir/cd analogy the thread starts with above.
>
>NACK, it's very similar to the cd "$HOME" (or ulimit calls) done by the
>login mechanism,

That's not a NACK.  The cd "$HOME" and ulimit calls done by the login 
process (more precisely, by a shell profile) are quite different from the 
mkdir/cd the thread started with.  Who creates a new directory in his 
shell profile?  I assume the mkdir/cd analogy is a case of a person doing 
a mkdir and cd in a running shell.  (That is indeed analogous to what one 
would like to do with a private mount).

When you said "by the login process or by wrappers like nice," in response 
to my pointing out that setnamespace would need to be a shell builtin 
command, I assumed you were talking about putting it in the code that 
execs the shell as opposed to in the shell profile, thus eliminating the 
need for a shell builtin.

But the important thing is just to recognize, as you say explicitly now, 
that setnamespace has to be shell builtin command for 
setnamespace/mknamespace to be analogous to mkdir/cd.  That was my 
original statement, if somewhat indirect:

>> >> >mknamespace -p users/$UID # (like mkdir -p)
>> >> >setnamespace users/$UID   # (like cd)
>> >>                               ^^^^^^^^
>> >> You realize that 'cd' is a shell command, and has to be, I hope. 
That 
>> >> little fact has thrown a wrench into many of the ideas in this 
thread.

--
Bryan Henderson                          IBM Almaden Research Center
San Jose CA                              Filesystems

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261239AbVD0ITm@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261239AbVD0ITm (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 27 Apr 2005 04:19:42 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261207AbVD0ITf
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 27 Apr 2005 04:19:35 -0400
Received: from mail-in-02.arcor-online.net ([151.189.21.42]:43447 "EHLO
	mail-in-02.arcor-online.net") by vger.kernel.org with ESMTP
	id S261189AbVD0ITX (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Apr 2005 04:19:23 -0400
Date: Wed, 27 Apr 2005 10:18:13 +0200 (CEST)
From: Bodo Eggert <7eggert@gmx.de>
To: Bryan Henderson <hbryan@us.ibm.com>
Cc: Bodo Eggert <7eggert@gmx.de>, akpm@osdl.org, Jan Hudec <bulb@ucw.cz>,
       hch@infradead.org, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org, Miklos Szeredi <miklos@szeredi.hu>,
       viro@parcelfarce.linux.theplanet.co.uk
Subject: Re: [PATCH] private mounts
In-Reply-To: <OFF84C9B1E.2214C52C-ON88256FEF.007799F7-88256FEF.0079B32B@us.ibm.com>
Message-ID: <Pine.LNX.4.58.0504270832180.2866@be1.lrz>
References: <OFF84C9B1E.2214C52C-ON88256FEF.007799F7-88256FEF.0079B32B@us.ibm.com>
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

On Tue, 26 Apr 2005, Bryan Henderson wrote:

> >> Just to be clear, then: this idea is fundamentally different from the 
> >> mkdir/cd analogy the thread starts with above.
> >
> >NACK, it's very similar to the cd "$HOME" (or ulimit calls) done by the
> >login mechanism,
> 
> That's not a NACK.  The cd "$HOME" and ulimit calls done by the login 
> process (more precisely, by a shell profile) are quite different from the 
> mkdir/cd the thread started with.  Who creates a new directory in his 
> shell profile?

I create a directory in /tmp and set $TMP to that directory, because I 
can't just mount a private tmpfs. But that's another topic.

>  I assume the mkdir/cd analogy is a case of a person doing 
> a mkdir and cd in a running shell.  (That is indeed analogous to what one 
> would like to do with a private mount).

ACK, with respect to lifetime and processes affected, it will be exactly
like creating/using a directory in a tmpfs. But as you noticed, you'd need
the shell builtin command to make this analogy complete. That's not going
to happen, but it's not needed for operation.

> When you said "by the login process or by wrappers like nice," in response 
> to my pointing out that setnamespace would need to be a shell builtin 
> command, I assumed you were talking about putting it in the code that 
> execs the shell as opposed to in the shell profile, thus eliminating the 
> need for a shell builtin.

Exactly. You can't patch all login daemons, so you'll need pam to do the
initial setup.

After that, the users may decide to ignore having a private namespace (it
will just DTRT), or they can decide to use that feature to lock in some of
their programs. Obviously pam won't allow private sub-namespaces at random
times, while the general system call would support this, and their shell
won't do that, too. In the same way you'll need a wrapper like "#!/bin/sh
cd $dir&&exec $prog" for doing the initial chdir on behalf of
chdir-ignorant programs, you'll need a wrapper for setnamespace-ignorant
programs. The only difference is that chdir-ignorant programs are rare.

> But the important thing is just to recognize, as you say explicitly now, 
> that setnamespace has to be shell builtin command for 
> setnamespace/mknamespace to be analogous to mkdir/cd.  That was my 
> original statement, if somewhat indirect:

For the analogy yes, for usage no.
-- 
The secret of the universe is #@*%! NO CARRIER 

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261267AbVD0Ium@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261267AbVD0Ium (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 27 Apr 2005 04:50:42 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261207AbVD0Iul
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 27 Apr 2005 04:50:41 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:36515 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S261190AbVD0Iub (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Apr 2005 04:50:31 -0400
To: pavel@ucw.cz
CC: hch@infradead.org, jamie@shareable.org, linuxram@us.ibm.com,
       7eggert@gmx.de, bulb@ucw.cz, viro@parcelfarce.linux.theplanet.co.uk,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
In-reply-to: <20050426201411.GA20109@elf.ucw.cz> (message from Pavel Machek on
	Tue, 26 Apr 2005 22:14:11 +0200)
Subject: Re: [PATCH] private mounts
References: <1114445923.4480.94.camel@localhost> <20050425191015.GC28294@mail.shareable.org> <E1DQMB0-00008a-00@dorka.pomaz.szeredi.hu> <20050426091921.GA29810@infradead.org> <E1DQMGZ-00009n-00@dorka.pomaz.szeredi.hu> <20050426093628.GA30208@infradead.org> <E1DQMYu-0000DL-00@dorka.pomaz.szeredi.hu> <20050426094727.GA30379@infradead.org> <20050426131943.GC2226@openzaurus.ucw.cz> <E1DQQ73-0000Zv-00@dorka.pomaz.szeredi.hu> <20050426201411.GA20109@elf.ucw.cz>
Message-Id: <E1DQiEa-0001hi-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Wed, 27 Apr 2005 10:49:28 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> > > Could we get root-only fuse in, please?
> > 
> > chmod u-s /usr/bin/fusermount
> 
> :-)))). I meant merging patches that are not controversial into
> mainline. AFAICT only controversial pieces are "make it safe for
> non-root users"...

This is the controversial part in all it's glory:

	if (!(fc->flags & FUSE_ALLOW_OTHER) && current->fsuid != fc->user_id)
		return -EACCES;

Leaving it out would gain us what exactly?

I'm not trying to say that this is somehow better than the
pam+shared-subtrees solution discuseed.  That certainly has advantages
over this (e.g. suid programs get permission to fuse mounted
filesystems).

But leaving it out makes no sense.  Zero, zilch, none.

Maybe I'm totally dumb, but I just don't get Christoph's argument.

Thanks,
Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261288AbVD0JKG@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261288AbVD0JKG (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 27 Apr 2005 05:10:06 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261299AbVD0JKG
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 27 Apr 2005 05:10:06 -0400
Received: from hermine.aitel.hist.no ([158.38.50.15]:45319 "HELO
	hermine.aitel.hist.no") by vger.kernel.org with SMTP
	id S261288AbVD0JKA (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Apr 2005 05:10:00 -0400
Message-ID: <426F57FB.4020404@aitel.hist.no>
Date: Wed, 27 Apr 2005 11:14:35 +0200
From: Helge Hafting <helge.hafting@aitel.hist.no>
User-Agent: Debian Thunderbird 1.0 (X11/20050116)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jamie Lokier <jamie@shareable.org>
CC: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>,
       Miklos Szeredi <miklos@szeredi.hu>, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
References: <E1DPnOn-0000T0-00@localhost> <20050424201820.GA28428@infradead.org> <E1DPo3I-0000V0-00@localhost> <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk> <E1DPoCg-0000W0-00@localhost> <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk> <E1DPoRz-0000Y0-00@localhost> <20050424211942.GN13052@parcelfarce.linux.theplanet.co.uk> <20050424214339.GD9304@mail.shareable.org>
In-Reply-To: <20050424214339.GD9304@mail.shareable.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Jamie Lokier wrote:

> He wants to do this:
>
>   1. From client, login to server and do a usermount on $HOME/private.
>
>   2. From client, login to server and read the files previously mounted.
>  
>
This is works fine with plain "mount", except that the mount isn't
hidden from others.  Why hide it?  Permissions can be used to prevent
others from looking at the mounted stuff if need be.  I.e. put
the mountpoint in a directory not readable by others, or
have the root of that fs unreadable by others.

Helge Hafting

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261269AbVD0JZV@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261269AbVD0JZV (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 27 Apr 2005 05:25:21 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261307AbVD0JZV
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 27 Apr 2005 05:25:21 -0400
Received: from gprs189-60.eurotel.cz ([160.218.189.60]:54404 "EHLO amd.ucw.cz")
	by vger.kernel.org with ESMTP id S261269AbVD0JZO (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Apr 2005 05:25:14 -0400
Date: Wed, 27 Apr 2005 11:24:50 +0200
From: Pavel Machek <pavel@suse.cz>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: hch@infradead.org, jamie@shareable.org, linuxram@us.ibm.com,
       7eggert@gmx.de, bulb@ucw.cz, viro@parcelfarce.linux.theplanet.co.uk,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050427092450.GB1819@elf.ucw.cz>
References: <E1DQMB0-00008a-00@dorka.pomaz.szeredi.hu> <20050426091921.GA29810@infradead.org> <E1DQMGZ-00009n-00@dorka.pomaz.szeredi.hu> <20050426093628.GA30208@infradead.org> <E1DQMYu-0000DL-00@dorka.pomaz.szeredi.hu> <20050426094727.GA30379@infradead.org> <20050426131943.GC2226@openzaurus.ucw.cz> <E1DQQ73-0000Zv-00@dorka.pomaz.szeredi.hu> <20050426201411.GA20109@elf.ucw.cz> <E1DQiEa-0001hi-00@dorka.pomaz.szeredi.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1DQiEa-0001hi-00@dorka.pomaz.szeredi.hu>
X-Warning: Reading this can be dangerous to your mental health.
User-Agent: Mutt/1.5.6+20040907i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Hi!

> > > > Could we get root-only fuse in, please?
> > > 
> > > chmod u-s /usr/bin/fusermount
> > 
> > :-)))). I meant merging patches that are not controversial into
> > mainline. AFAICT only controversial pieces are "make it safe for
> > non-root users"...
> 
> This is the controversial part in all it's glory:
> 
> 	if (!(fc->flags & FUSE_ALLOW_OTHER) && current->fsuid != fc->user_id)
> 		return -EACCES;
> 
> Leaving it out would gain us what exactly?

Well, if it brings us ugly semantics, keeping those two lines out for
a while can help merge a lot...
								Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261396AbVD0Kne@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261396AbVD0Kne (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 27 Apr 2005 06:43:34 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261398AbVD0KnT
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 27 Apr 2005 06:43:19 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:55459 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S261396AbVD0KnH (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Apr 2005 06:43:07 -0400
To: pavel@suse.cz
CC: hch@infradead.org, jamie@shareable.org, linuxram@us.ibm.com,
       7eggert@gmx.de, bulb@ucw.cz, viro@parcelfarce.linux.theplanet.co.uk,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
In-reply-to: <20050427092450.GB1819@elf.ucw.cz> (message from Pavel Machek on
	Wed, 27 Apr 2005 11:24:50 +0200)
Subject: Re: [PATCH] private mounts
References: <E1DQMB0-00008a-00@dorka.pomaz.szeredi.hu> <20050426091921.GA29810@infradead.org> <E1DQMGZ-00009n-00@dorka.pomaz.szeredi.hu> <20050426093628.GA30208@infradead.org> <E1DQMYu-0000DL-00@dorka.pomaz.szeredi.hu> <20050426094727.GA30379@infradead.org> <20050426131943.GC2226@openzaurus.ucw.cz> <E1DQQ73-0000Zv-00@dorka.pomaz.szeredi.hu> <20050426201411.GA20109@elf.ucw.cz> <E1DQiEa-0001hi-00@dorka.pomaz.szeredi.hu> <20050427092450.GB1819@elf.ucw.cz>
Message-Id: <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Wed, 27 Apr 2005 12:42:04 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> > This is the controversial part in all it's glory:
> > 
> > 	if (!(fc->flags & FUSE_ALLOW_OTHER) && current->fsuid != fc->user_id)
> > 		return -EACCES;
> > 
> > Leaving it out would gain us what exactly?
> 
> Well, if it brings us ugly semantics, keeping those two lines out for
> a while can help merge a lot...

To the mount owner the semantics are quite normal.  Others will be
denied access to the mountpoint, which doesn't introduce any new
semantics either.

If you look at it from the POV of _any_ process, there are NO NEW
SEMANTICS.  Nothing that programs, scripts or anything has to be
modified for.  Nothing that could cause _any_ problems later, if this
check was removed.

Prove me wrong!

Thanks,
Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261489AbVD0MAi@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261489AbVD0MAi (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 27 Apr 2005 08:00:38 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261515AbVD0MAg
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 27 Apr 2005 08:00:36 -0400
Received: from cimice4.lam.cz ([212.71.168.94]:49846 "EHLO vagabond.light.src")
	by vger.kernel.org with ESMTP id S261489AbVD0MAY (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Apr 2005 08:00:24 -0400
Date: Wed, 27 Apr 2005 13:57:54 +0200
From: Jan Hudec <bulb@ucw.cz>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: pavel@suse.cz, hch@infradead.org, jamie@shareable.org, linuxram@us.ibm.com,
       7eggert@gmx.de, viro@parcelfarce.linux.theplanet.co.uk,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050427115754.GA8981@vagabond>
References: <E1DQMGZ-00009n-00@dorka.pomaz.szeredi.hu> <20050426093628.GA30208@infradead.org> <E1DQMYu-0000DL-00@dorka.pomaz.szeredi.hu> <20050426094727.GA30379@infradead.org> <20050426131943.GC2226@openzaurus.ucw.cz> <E1DQQ73-0000Zv-00@dorka.pomaz.szeredi.hu> <20050426201411.GA20109@elf.ucw.cz> <E1DQiEa-0001hi-00@dorka.pomaz.szeredi.hu> <20050427092450.GB1819@elf.ucw.cz> <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI"
Content-Disposition: inline
In-Reply-To: <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu>
User-Agent: Mutt/1.5.9i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org


--oyUTqETQ0mS9luUI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 27, 2005 at 12:42:04 +0200, Miklos Szeredi wrote:
> > > This is the controversial part in all it's glory:
> > >=20
> > > 	if (!(fc->flags & FUSE_ALLOW_OTHER) && current->fsuid !=3D fc->user_=
id)
> > > 		return -EACCES;
> > >=20
> > > Leaving it out would gain us what exactly?
> >=20
> > Well, if it brings us ugly semantics, keeping those two lines out for
> > a while can help merge a lot...
>=20
> To the mount owner the semantics are quite normal.  Others will be
> denied access to the mountpoint, which doesn't introduce any new
> semantics either.

What makes you think Pavel was talking about semantics?!

The point was that:
Ok, there is a strong disagreement about these two lines. Could we have
a patch with everything but these two lines, so it can be integrated
immediately to profit of the testing and generally be useful, and then
the controversial bits when the issue is beaten to death?

So, please, could you send a stripped-down version, that is not safe for
mounting by users, but can be tested for many cases where that is
sufficient?

> If you look at it from the POV of _any_ process, there are NO NEW
> SEMANTICS.  Nothing that programs, scripts or anything has to be
> modified for.  Nothing that could cause _any_ problems later, if this
> check was removed.
>=20
> Prove me wrong!

As I understand it, doing things like this is butt ugly. Not just in
fuse -- in NFS, in samba, everywhere where such hacks are employed. But
now they just have enough of those hacks and want a cleaner solution.

---------------------------------------------------------------------------=
----
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

--oyUTqETQ0mS9luUI
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCb35CRel1vVwhjGURApqsAKDv4ro7NEKrI2CCT7kNU8Y29EmbOQCfeMmV
mOz00Q5hxBXtxctkvIM1NEc=
=SjGs
-----END PGP SIGNATURE-----

--oyUTqETQ0mS9luUI--

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261535AbVD0MZM@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261535AbVD0MZM (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 27 Apr 2005 08:25:12 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261531AbVD0MZL
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 27 Apr 2005 08:25:11 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:9892 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S261525AbVD0MZC (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Apr 2005 08:25:02 -0400
To: bulb@ucw.cz
CC: pavel@suse.cz, hch@infradead.org, jamie@shareable.org, linuxram@us.ibm.com,
       7eggert@gmx.de, viro@parcelfarce.linux.theplanet.co.uk,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
In-reply-to: <20050427115754.GA8981@vagabond> (message from Jan Hudec on Wed,
	27 Apr 2005 13:57:54 +0200)
Subject: Re: [PATCH] private mounts
References: <E1DQMGZ-00009n-00@dorka.pomaz.szeredi.hu> <20050426093628.GA30208@infradead.org> <E1DQMYu-0000DL-00@dorka.pomaz.szeredi.hu> <20050426094727.GA30379@infradead.org> <20050426131943.GC2226@openzaurus.ucw.cz> <E1DQQ73-0000Zv-00@dorka.pomaz.szeredi.hu> <20050426201411.GA20109@elf.ucw.cz> <E1DQiEa-0001hi-00@dorka.pomaz.szeredi.hu> <20050427092450.GB1819@elf.ucw.cz> <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu> <20050427115754.GA8981@vagabond>
Message-Id: <E1DQla0-0001vG-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Wed, 27 Apr 2005 14:23:48 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> What makes you think Pavel was talking about semantics?!

    Well, if it brings us ugly semantics, keeping those two lines out for
                               ^^^^^^^^^
    a while can help merge a lot...

> The point was that:
> Ok, there is a strong disagreement about these two lines. Could we have
> a patch with everything but these two lines, so it can be integrated
> immediately to profit of the testing and generally be useful, and then
> the controversial bits when the issue is beaten to death?

I could remove this check.

But it would only cause confusion.  How would the userspace utilities
differentiate between the safe out-of-kernel and the unsafe in-kernel
module?  Adding hacks to make this possible is far more ugly IMO than
integrating the current well tested solution.

It makes no sense.  If someone would give me a rational explanation
why it is bad, I would be content.  But you just tell me it's
terrible, ugly, crap which may well be true, but are not technical
terms, which I can relate to.

> As I understand it, doing things like this is butt ugly. Not just in
> fuse -- in NFS, in samba, everywhere where such hacks are employed. But
> now they just have enough of those hacks and want a cleaner solution.

Please do.  I want it too.

_When_ we have a better solution, all the hacks can be removed, and
the world will rejoice.

Until then, let the hacks live!  Please!

Thanks,
Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261542AbVD0MnF@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261542AbVD0MnF (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 27 Apr 2005 08:43:05 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261543AbVD0Mmy
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 27 Apr 2005 08:42:54 -0400
Received: from cimice4.lam.cz ([212.71.168.94]:62902 "EHLO vagabond.light.src")
	by vger.kernel.org with ESMTP id S261542AbVD0Mks (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Apr 2005 08:40:48 -0400
Date: Wed, 27 Apr 2005 14:39:44 +0200
From: Jan Hudec <bulb@ucw.cz>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: pavel@suse.cz, hch@infradead.org, jamie@shareable.org, linuxram@us.ibm.com,
       7eggert@gmx.de, viro@parcelfarce.linux.theplanet.co.uk,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050427123944.GA11020@vagabond>
References: <E1DQMYu-0000DL-00@dorka.pomaz.szeredi.hu> <20050426094727.GA30379@infradead.org> <20050426131943.GC2226@openzaurus.ucw.cz> <E1DQQ73-0000Zv-00@dorka.pomaz.szeredi.hu> <20050426201411.GA20109@elf.ucw.cz> <E1DQiEa-0001hi-00@dorka.pomaz.szeredi.hu> <20050427092450.GB1819@elf.ucw.cz> <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu> <20050427115754.GA8981@vagabond> <E1DQla0-0001vG-00@dorka.pomaz.szeredi.hu>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="fdj2RfSjLxBAspz7"
Content-Disposition: inline
In-Reply-To: <E1DQla0-0001vG-00@dorka.pomaz.szeredi.hu>
User-Agent: Mutt/1.5.9i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org


--fdj2RfSjLxBAspz7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 27, 2005 at 14:23:48 +0200, Miklos Szeredi wrote:
> > What makes you think Pavel was talking about semantics?!
>=20
>     Well, if it brings us ugly semantics, keeping those two lines out for
>                                ^^^^^^^^^
>     a while can help merge a lot...
>=20
> > The point was that:
> > Ok, there is a strong disagreement about these two lines. Could we have
> > a patch with everything but these two lines, so it can be integrated
> > immediately to profit of the testing and generally be useful, and then
> > the controversial bits when the issue is beaten to death?
>=20
> I could remove this check.
>=20
> But it would only cause confusion.  How would the userspace utilities
> differentiate between the safe out-of-kernel and the unsafe in-kernel
> module?  Adding hacks to make this possible is far more ugly IMO than
> integrating the current well tested solution.
>=20
> It makes no sense.  If someone would give me a rational explanation
> why it is bad, I would be content.  But you just tell me it's
> terrible, ugly, crap which may well be true, but are not technical
> terms, which I can relate to.

Where the hell do you see it above. The only thing I said above is it is
controversial.

The userland tools don't need to know. They just need to not be suid.

> > As I understand it, doing things like this is butt ugly. Not just in
> > fuse -- in NFS, in samba, everywhere where such hacks are employed. But
> > now they just have enough of those hacks and want a cleaner solution.
>=20
> Please do.  I want it too.
>=20
> _When_ we have a better solution, all the hacks can be removed, and
> the world will rejoice.
>=20
> Until then, let the hacks live!  Please!

Ok, here I say it is ugly (but not that it's crap). And the reason is,
that there is a permission system, with some semantics, and then various
filesystems adapt it in varous ways to fit what they want. So every
filesystem ends up with it's onw little different behaviour.

That being said, fuse does just about the same as NFS, samba and others
and I don't really see the reason why it couldn't be integrated. But
I am not the one to decide.

---------------------------------------------------------------------------=
----
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

--fdj2RfSjLxBAspz7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCb4gQRel1vVwhjGURAunBAJ0Ybg56uPEfFWLK2eAG2iRcIIrCkQCfbs6y
tjSaFOB5BVKwlWd8R3YfcYc=
=WXHD
-----END PGP SIGNATURE-----

--fdj2RfSjLxBAspz7--

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261309AbVD0NXu@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261309AbVD0NXu (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 27 Apr 2005 09:23:50 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261312AbVD0NXu
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 27 Apr 2005 09:23:50 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:21924 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S261309AbVD0NXU (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Apr 2005 09:23:20 -0400
To: bulb@ucw.cz
CC: pavel@suse.cz, hch@infradead.org, jamie@shareable.org, linuxram@us.ibm.com,
       7eggert@gmx.de, viro@parcelfarce.linux.theplanet.co.uk,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
In-reply-to: <20050427123944.GA11020@vagabond> (message from Jan Hudec on Wed,
	27 Apr 2005 14:39:44 +0200)
Subject: Re: [PATCH] private mounts
References: <E1DQMYu-0000DL-00@dorka.pomaz.szeredi.hu> <20050426094727.GA30379@infradead.org> <20050426131943.GC2226@openzaurus.ucw.cz> <E1DQQ73-0000Zv-00@dorka.pomaz.szeredi.hu> <20050426201411.GA20109@elf.ucw.cz> <E1DQiEa-0001hi-00@dorka.pomaz.szeredi.hu> <20050427092450.GB1819@elf.ucw.cz> <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu> <20050427115754.GA8981@vagabond> <E1DQla0-0001vG-00@dorka.pomaz.szeredi.hu> <20050427123944.GA11020@vagabond>
Message-Id: <E1DQmUm-0001yy-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Wed, 27 Apr 2005 15:22:28 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> > It makes no sense.  If someone would give me a rational explanation
> > why it is bad, I would be content.  But you just tell me it's
> > terrible, ugly, crap which may well be true, but are not technical
> > terms, which I can relate to.
> 
> Where the hell do you see it above.

I meant it as a plural "you" mainly refering to Christoph, who did use
those words, and not too sparingly either :)

I did not mean it personally, please accept my apologies.

> The userland tools don't need to know. They just need to not be suid.

But I'd want to continue distribute the non-crippled kernel module
too, with suid fusermount.  Then fusermount _has_ to know which kernel
module is currently active.

> Ok, here I say it is ugly (but not that it's crap). And the reason is,
> that there is a permission system, with some semantics, and then various
> filesystems adapt it in varous ways to fit what they want. So every
> filesystem ends up with it's onw little different behaviour.
> 
> That being said, fuse does just about the same as NFS, samba and others
> and I don't really see the reason why it couldn't be integrated. But
> I am not the one to decide.

Every opinion counts.

I'm not trying to convince people that the current solution is
perfect.  What I'm saying that it's

  a) not harmful

  b) it makes non-privileged mounts possible

And b) is _the_ most important feature IMO, so the argument for
stripping it out has to be very good.

Thanks,
Miklos


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261659AbVD0Ocx@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261659AbVD0Ocx (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 27 Apr 2005 10:32:53 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261640AbVD0Ocw
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 27 Apr 2005 10:32:52 -0400
Received: from mail.shareable.org ([81.29.64.88]:54185 "EHLO
	mail.shareable.org") by vger.kernel.org with ESMTP id S261662AbVD0Ocf
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Apr 2005 10:32:35 -0400
Date: Wed, 27 Apr 2005 15:31:26 +0100
From: Jamie Lokier <jamie@shareable.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: pavel@suse.cz, hch@infradead.org, linuxram@us.ibm.com, 7eggert@gmx.de,
       bulb@ucw.cz, viro@parcelfarce.linux.theplanet.co.uk,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050427143126.GB1957@mail.shareable.org>
References: <E1DQMGZ-00009n-00@dorka.pomaz.szeredi.hu> <20050426093628.GA30208@infradead.org> <E1DQMYu-0000DL-00@dorka.pomaz.szeredi.hu> <20050426094727.GA30379@infradead.org> <20050426131943.GC2226@openzaurus.ucw.cz> <E1DQQ73-0000Zv-00@dorka.pomaz.szeredi.hu> <20050426201411.GA20109@elf.ucw.cz> <E1DQiEa-0001hi-00@dorka.pomaz.szeredi.hu> <20050427092450.GB1819@elf.ucw.cz> <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Miklos Szeredi wrote:
> > > This is the controversial part in all it's glory:
> > > 
> > > 	if (!(fc->flags & FUSE_ALLOW_OTHER) && current->fsuid != fc->user_id)
> > > 		return -EACCES;
> > > 
> > > Leaving it out would gain us what exactly?
> > 
> > Well, if it brings us ugly semantics, keeping those two lines out for
> > a while can help merge a lot...
> 
> To the mount owner the semantics are quite normal.  Others will be
> denied access to the mountpoint, which doesn't introduce any new
> semantics either.

Why, exactly, is this check in the kernel and not the FUSE daemon?

Someone said the FUSE daemon knows which user is making filesystem
requests, and can therefore do this.  Is it true?

-- Jamie

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261671AbVD0Okt@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261671AbVD0Okt (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 27 Apr 2005 10:40:49 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261668AbVD0Okt
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 27 Apr 2005 10:40:49 -0400
Received: from mail.shareable.org ([81.29.64.88]:57257 "EHLO
	mail.shareable.org") by vger.kernel.org with ESMTP id S261660AbVD0Okj
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Apr 2005 10:40:39 -0400
Date: Wed, 27 Apr 2005 15:40:22 +0100
From: Jamie Lokier <jamie@shareable.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: bulb@ucw.cz, pavel@suse.cz, hch@infradead.org, linuxram@us.ibm.com,
       7eggert@gmx.de, viro@parcelfarce.linux.theplanet.co.uk,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050427144022.GD1957@mail.shareable.org>
References: <20050426131943.GC2226@openzaurus.ucw.cz> <E1DQQ73-0000Zv-00@dorka.pomaz.szeredi.hu> <20050426201411.GA20109@elf.ucw.cz> <E1DQiEa-0001hi-00@dorka.pomaz.szeredi.hu> <20050427092450.GB1819@elf.ucw.cz> <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu> <20050427115754.GA8981@vagabond> <E1DQla0-0001vG-00@dorka.pomaz.szeredi.hu> <20050427123944.GA11020@vagabond> <E1DQmUm-0001yy-00@dorka.pomaz.szeredi.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1DQmUm-0001yy-00@dorka.pomaz.szeredi.hu>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Miklos Szeredi wrote:
> > The userland tools don't need to know. They just need to not be suid.
> 
> But I'd want to continue distribute the non-crippled kernel module
> too, with suid fusermount.  Then fusermount _has_ to know which kernel
> module is currently active.

You can use a version number or feature-bitmask for that.

-- Jamie

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261668AbVD0OrZ@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261668AbVD0OrZ (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 27 Apr 2005 10:47:25 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261662AbVD0OrY
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 27 Apr 2005 10:47:24 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:48804 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S261660AbVD0OrT (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Apr 2005 10:47:19 -0400
To: jamie@shareable.org
CC: pavel@suse.cz, hch@infradead.org, linuxram@us.ibm.com, 7eggert@gmx.de,
       bulb@ucw.cz, viro@parcelfarce.linux.theplanet.co.uk,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
In-reply-to: <20050427143126.GB1957@mail.shareable.org> (message from Jamie
	Lokier on Wed, 27 Apr 2005 15:31:26 +0100)
Subject: Re: [PATCH] private mounts
References: <E1DQMGZ-00009n-00@dorka.pomaz.szeredi.hu> <20050426093628.GA30208@infradead.org> <E1DQMYu-0000DL-00@dorka.pomaz.szeredi.hu> <20050426094727.GA30379@infradead.org> <20050426131943.GC2226@openzaurus.ucw.cz> <E1DQQ73-0000Zv-00@dorka.pomaz.szeredi.hu> <20050426201411.GA20109@elf.ucw.cz> <E1DQiEa-0001hi-00@dorka.pomaz.szeredi.hu> <20050427092450.GB1819@elf.ucw.cz> <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu> <20050427143126.GB1957@mail.shareable.org>
Message-Id: <E1DQno0-00029a-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Wed, 27 Apr 2005 16:46:24 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> Why, exactly, is this check in the kernel and not the FUSE daemon?
> 
> Someone said the FUSE daemon knows which user is making filesystem
> requests, and can therefore do this.  Is it true?

Yes.

The check is in the kernel, because otherwise it couldn't be enforced.

It is not there for the purpose of protecting user's data.  Rather for
protecting other users (including root) from unknowingly entering the
FUSE directory and thus leaking otherwise inaccessible information
(exact file operations performed) to the mount owner.

It's probably not a great security risk, but it's better to be safe
than sorry.  If a sysadmin decides, it's not problematic, he can
relax this by 

  echo user_allow_other >> /etc/fuse.conf

Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261704AbVD0O4S@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261704AbVD0O4S (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 27 Apr 2005 10:56:18 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261700AbVD0O4S
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 27 Apr 2005 10:56:18 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:52644 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S261694AbVD0O4D (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Apr 2005 10:56:03 -0400
To: miklos@szeredi.hu
CC: jamie@shareable.org, pavel@suse.cz, hch@infradead.org, linuxram@us.ibm.com,
       7eggert@gmx.de, bulb@ucw.cz, viro@parcelfarce.linux.theplanet.co.uk,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
In-reply-to: <E1DQno0-00029a-00@dorka.pomaz.szeredi.hu> (message from Miklos
	Szeredi on Wed, 27 Apr 2005 16:46:24 +0200)
Subject: Re: [PATCH] private mounts
References: <E1DQMGZ-00009n-00@dorka.pomaz.szeredi.hu> <20050426093628.GA30208@infradead.org> <E1DQMYu-0000DL-00@dorka.pomaz.szeredi.hu> <20050426094727.GA30379@infradead.org> <20050426131943.GC2226@openzaurus.ucw.cz> <E1DQQ73-0000Zv-00@dorka.pomaz.szeredi.hu> <20050426201411.GA20109@elf.ucw.cz> <E1DQiEa-0001hi-00@dorka.pomaz.szeredi.hu> <20050427092450.GB1819@elf.ucw.cz> <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu> <20050427143126.GB1957@mail.shareable.org> <E1DQno0-00029a-00@dorka.pomaz.szeredi.hu>
Message-Id: <E1DQnwr-0002Aj-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Wed, 27 Apr 2005 16:55:33 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> > Why, exactly, is this check in the kernel and not the FUSE daemon?
> > 
> > Someone said the FUSE daemon knows which user is making filesystem
> > requests, and can therefore do this.  Is it true?
> 
> Yes.
> 
> The check is in the kernel, because otherwise it couldn't be enforced.

I'm going to compile a fuse-user-mount FAQ.  This is about the 4th
time I answer this question in this thread :)

Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261609AbVD0Pdf@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261609AbVD0Pdf (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 27 Apr 2005 11:33:35 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261617AbVD0Pd3
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 27 Apr 2005 11:33:29 -0400
Received: from atrey.karlin.mff.cuni.cz ([195.113.31.123]:2974 "EHLO
	atrey.karlin.mff.cuni.cz") by vger.kernel.org with ESMTP
	id S261609AbVD0PdW (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Apr 2005 11:33:22 -0400
Date: Wed, 27 Apr 2005 17:33:20 +0200
From: Martin Mares <mj@ucw.cz>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: jamie@shareable.org, pavel@suse.cz, hch@infradead.org, linuxram@us.ibm.com,
       7eggert@gmx.de, bulb@ucw.cz, viro@parcelfarce.linux.theplanet.co.uk,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050427153320.GA19065@atrey.karlin.mff.cuni.cz>
References: <E1DQMYu-0000DL-00@dorka.pomaz.szeredi.hu> <20050426094727.GA30379@infradead.org> <20050426131943.GC2226@openzaurus.ucw.cz> <E1DQQ73-0000Zv-00@dorka.pomaz.szeredi.hu> <20050426201411.GA20109@elf.ucw.cz> <E1DQiEa-0001hi-00@dorka.pomaz.szeredi.hu> <20050427092450.GB1819@elf.ucw.cz> <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu> <20050427143126.GB1957@mail.shareable.org> <E1DQno0-00029a-00@dorka.pomaz.szeredi.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1DQno0-00029a-00@dorka.pomaz.szeredi.hu>
User-Agent: Mutt/1.5.6+20040907i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Hello!

> It is not there for the purpose of protecting user's data.  Rather for
> protecting other users (including root) from unknowingly entering the
> FUSE directory and thus leaking otherwise inaccessible information
> (exact file operations performed) to the mount owner.

Huh? Do you really suppose that there could be anything secret in the
operations somebody else is performing on your files?

I still don't see any real problem this check could ever solve.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
God is real, unless declared integer.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261756AbVD0Puv@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261756AbVD0Puv (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 27 Apr 2005 11:50:51 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261780AbVD0Puv
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 27 Apr 2005 11:50:51 -0400
Received: from gate.in-addr.de ([212.8.193.158]:26560 "EHLO mx.in-addr.de")
	by vger.kernel.org with ESMTP id S261756AbVD0Pud (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Apr 2005 11:50:33 -0400
Date: Wed, 27 Apr 2005 17:50:22 +0200
From: Lars Marowsky-Bree <lmb@suse.de>
To: Martin Mares <mj@ucw.cz>, Miklos Szeredi <miklos@szeredi.hu>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050427155022.GR4431@marowsky-bree.de>
References: <20050426094727.GA30379@infradead.org> <20050426131943.GC2226@openzaurus.ucw.cz> <E1DQQ73-0000Zv-00@dorka.pomaz.szeredi.hu> <20050426201411.GA20109@elf.ucw.cz> <E1DQiEa-0001hi-00@dorka.pomaz.szeredi.hu> <20050427092450.GB1819@elf.ucw.cz> <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu> <20050427143126.GB1957@mail.shareable.org> <E1DQno0-00029a-00@dorka.pomaz.szeredi.hu> <20050427153320.GA19065@atrey.karlin.mff.cuni.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20050427153320.GA19065@atrey.karlin.mff.cuni.cz>
X-Ctuhulu: HASTUR
User-Agent: Mutt/1.5.6i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On 2005-04-27T17:33:20, Martin Mares <mj@ucw.cz> wrote:

> > It is not there for the purpose of protecting user's data.  Rather for
> > protecting other users (including root) from unknowingly entering the
> > FUSE directory and thus leaking otherwise inaccessible information
> > (exact file operations performed) to the mount owner.
> 
> Huh? Do you really suppose that there could be anything secret in the
> operations somebody else is performing on your files?

It is certainly an information leak not otherwise available. And with
the ability to change the layout underneath, you might trigger bugs in
root programs: Are they really capable of seeing the same filename
twice, or can you throw them into a deep recursion by simulating
infinitely deep directories/circular hardlinks...?

Certainly a useful tool for hardening applications, but I can see the
point of not wanting to let unwary applications run into a namespace
controlled by a user. Of course, this is sort-of similar to "find
-xdev", but I'm not sure whether it is not indeed new behaviour.



Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261798AbVD0Qqz@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261798AbVD0Qqz (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 27 Apr 2005 12:46:55 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261803AbVD0Qqz
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 27 Apr 2005 12:46:55 -0400
Received: from albireo.ucw.cz ([84.242.65.67]:44161 "EHLO albireo.ucw.cz")
	by vger.kernel.org with ESMTP id S261798AbVD0Qqv (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Apr 2005 12:46:51 -0400
Date: Wed, 27 Apr 2005 18:46:52 +0200
From: Martin Mares <mj@ucw.cz>
To: Lars Marowsky-Bree <lmb@suse.de>
Cc: Miklos Szeredi <miklos@szeredi.hu>, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050427164652.GA3129@ucw.cz>
References: <20050426131943.GC2226@openzaurus.ucw.cz> <E1DQQ73-0000Zv-00@dorka.pomaz.szeredi.hu> <20050426201411.GA20109@elf.ucw.cz> <E1DQiEa-0001hi-00@dorka.pomaz.szeredi.hu> <20050427092450.GB1819@elf.ucw.cz> <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu> <20050427143126.GB1957@mail.shareable.org> <E1DQno0-00029a-00@dorka.pomaz.szeredi.hu> <20050427153320.GA19065@atrey.karlin.mff.cuni.cz> <20050427155022.GR4431@marowsky-bree.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050427155022.GR4431@marowsky-bree.de>
User-Agent: Mutt/1.3.28i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Hello!

> It is certainly an information leak not otherwise available. And with
> the ability to change the layout underneath, you might trigger bugs in
> root programs: Are they really capable of seeing the same filename
> twice, or can you throw them into a deep recursion by simulating
> infinitely deep directories/circular hardlinks...?

Yes, it can help you trigger bugs, but all these bugs are triggerable
without user filesystems as well, although it's harder to do so.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
If the government wants us to respect the law, it should set a better example.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261827AbVD0Rem@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261827AbVD0Rem (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 27 Apr 2005 13:34:42 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261835AbVD0ReY
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 27 Apr 2005 13:34:24 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:20645 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S261827AbVD0ReO (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Apr 2005 13:34:14 -0400
To: lmb@suse.de
CC: mj@ucw.cz, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
In-reply-to: <20050427155022.GR4431@marowsky-bree.de> (message from Lars
	Marowsky-Bree on Wed, 27 Apr 2005 17:50:22 +0200)
Subject: Re: [PATCH] private mounts
References: <20050426094727.GA30379@infradead.org> <20050426131943.GC2226@openzaurus.ucw.cz> <E1DQQ73-0000Zv-00@dorka.pomaz.szeredi.hu> <20050426201411.GA20109@elf.ucw.cz> <E1DQiEa-0001hi-00@dorka.pomaz.szeredi.hu> <20050427092450.GB1819@elf.ucw.cz> <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu> <20050427143126.GB1957@mail.shareable.org> <E1DQno0-00029a-00@dorka.pomaz.szeredi.hu> <20050427153320.GA19065@atrey.karlin.mff.cuni.cz> <20050427155022.GR4431@marowsky-bree.de>
Message-Id: <E1DQqQ0-0002PB-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Wed, 27 Apr 2005 19:33:48 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> It is certainly an information leak not otherwise available. And with
> the ability to change the layout underneath, you might trigger bugs in
> root programs: Are they really capable of seeing the same filename
> twice, or can you throw them into a deep recursion by simulating
> infinitely deep directories/circular hardlinks...?

Circular or otherwise hardlinked directories are not allowed since it
would not only confuse applications but the VFS as well.

Hmm, looking at the code it seems that for some reason I removed this
check from the 2.6 version of FUSE.  Stupid me!

Thanks for the reminder :)

> Certainly a useful tool for hardening applications, but I can see the
> point of not wanting to let unwary applications run into a namespace
> controlled by a user. Of course, this is sort-of similar to "find
> -xdev", but I'm not sure whether it is not indeed new behaviour.

A trivial DoS against any process entering the userspace filesystem is
just not to answer the filesystem request.

So it's not just information leak, but also a fine way to _control_
certain behavior of applications.

Thanks,
Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261839AbVD0RkF@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261839AbVD0RkF (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 27 Apr 2005 13:40:05 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261842AbVD0Rjq
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 27 Apr 2005 13:39:46 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:22437 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S261841AbVD0Riv (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Apr 2005 13:38:51 -0400
To: mj@ucw.cz
CC: lmb@suse.de, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
In-reply-to: <20050427164652.GA3129@ucw.cz> (message from Martin Mares on Wed,
	27 Apr 2005 18:46:52 +0200)
Subject: Re: [PATCH] private mounts
References: <20050426131943.GC2226@openzaurus.ucw.cz> <E1DQQ73-0000Zv-00@dorka.pomaz.szeredi.hu> <20050426201411.GA20109@elf.ucw.cz> <E1DQiEa-0001hi-00@dorka.pomaz.szeredi.hu> <20050427092450.GB1819@elf.ucw.cz> <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu> <20050427143126.GB1957@mail.shareable.org> <E1DQno0-00029a-00@dorka.pomaz.szeredi.hu> <20050427153320.GA19065@atrey.karlin.mff.cuni.cz> <20050427155022.GR4431@marowsky-bree.de> <20050427164652.GA3129@ucw.cz>
Message-Id: <E1DQqUi-0002Pt-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Wed, 27 Apr 2005 19:38:40 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> > It is certainly an information leak not otherwise available. And with
> > the ability to change the layout underneath, you might trigger bugs in
> > root programs: Are they really capable of seeing the same filename
> > twice, or can you throw them into a deep recursion by simulating
> > infinitely deep directories/circular hardlinks...?
> 
> Yes, it can help you trigger bugs, but all these bugs are triggerable
> without user filesystems as well, although it's harder to do so.

It's not just triggering bugs.  You have very fine control over what
you present in your filesystem.  Examples are huge files, huge
directories, operations that complete slowly or never at all.

Is it possible to limit all these from kernelspace?  Probably yes,
although a timeout for operations is something that cuts either way.
And the compexity of these checks would probably be orders of
magnitude higher then the check we are currently discussing.

So this check _is_ needed on systems where the users cannot be trusted.

Thanks,
Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261850AbVD0Rmo@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261850AbVD0Rmo (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 27 Apr 2005 13:42:44 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261851AbVD0Rkm
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 27 Apr 2005 13:40:42 -0400
Received: from e32.co.us.ibm.com ([32.97.110.130]:34045 "EHLO
	e32.co.us.ibm.com") by vger.kernel.org with ESMTP id S261841AbVD0RkF
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Apr 2005 13:40:05 -0400
Subject: Re: [PATCH] private mounts
From: Ram <linuxram@us.ibm.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: lmb@suse.de, mj@ucw.cz, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org
In-Reply-To: <E1DQqQ0-0002PB-00@dorka.pomaz.szeredi.hu>
References: <20050426094727.GA30379@infradead.org>
	 <20050426131943.GC2226@openzaurus.ucw.cz>
	 <E1DQQ73-0000Zv-00@dorka.pomaz.szeredi.hu>
	 <20050426201411.GA20109@elf.ucw.cz>
	 <E1DQiEa-0001hi-00@dorka.pomaz.szeredi.hu>
	 <20050427092450.GB1819@elf.ucw.cz>
	 <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu>
	 <20050427143126.GB1957@mail.shareable.org>
	 <E1DQno0-00029a-00@dorka.pomaz.szeredi.hu>
	 <20050427153320.GA19065@atrey.karlin.mff.cuni.cz>
	 <20050427155022.GR4431@marowsky-bree.de>
	 <E1DQqQ0-0002PB-00@dorka.pomaz.szeredi.hu>
Content-Type: text/plain
Organization: IBM 
Message-Id: <1114623598.4480.181.camel@localhost>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 
Date: Wed, 27 Apr 2005 10:39:59 -0700
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, 2005-04-27 at 10:33, Miklos Szeredi wrote:
> > It is certainly an information leak not otherwise available. And with
> > the ability to change the layout underneath, you might trigger bugs in
> > root programs: Are they really capable of seeing the same filename
> > twice, or can you throw them into a deep recursion by simulating
> > infinitely deep directories/circular hardlinks...?
> 
> Circular or otherwise hardlinked directories are not allowed since it
> would not only confuse applications but the VFS as well.
> 
> Hmm, looking at the code it seems that for some reason I removed this
> check from the 2.6 version of FUSE.  Stupid me!
> 
> Thanks for the reminder :)
> 
> > Certainly a useful tool for hardening applications, but I can see the
> > point of not wanting to let unwary applications run into a namespace
> > controlled by a user. Of course, this is sort-of similar to "find
> > -xdev", but I'm not sure whether it is not indeed new behaviour.
> 
> A trivial DoS against any process entering the userspace filesystem is
> just not to answer the filesystem request.
> 
> So it's not just information leak, but also a fine way to _control_
> certain behavior of applications.
> 

I think you need to disallow overmounts on invisible mounts by any user
other than the owner. If not, some other user (including root) can
overmount on your mount and the user will end up with DoS.

RP

> Thanks,
> Miklos
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261863AbVD0RtA@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261863AbVD0RtA (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 27 Apr 2005 13:49:00 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261841AbVD0Rs4
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 27 Apr 2005 13:48:56 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:28837 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S261857AbVD0Rr5 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Apr 2005 13:47:57 -0400
To: linuxram@us.ibm.com
CC: lmb@suse.de, mj@ucw.cz, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org
In-reply-to: <1114623598.4480.181.camel@localhost> (message from Ram on Wed,
	27 Apr 2005 10:39:59 -0700)
Subject: Re: [PATCH] private mounts
References: <20050426094727.GA30379@infradead.org>
	 <20050426131943.GC2226@openzaurus.ucw.cz>
	 <E1DQQ73-0000Zv-00@dorka.pomaz.szeredi.hu>
	 <20050426201411.GA20109@elf.ucw.cz>
	 <E1DQiEa-0001hi-00@dorka.pomaz.szeredi.hu>
	 <20050427092450.GB1819@elf.ucw.cz>
	 <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu>
	 <20050427143126.GB1957@mail.shareable.org>
	 <E1DQno0-00029a-00@dorka.pomaz.szeredi.hu>
	 <20050427153320.GA19065@atrey.karlin.mff.cuni.cz>
	 <20050427155022.GR4431@marowsky-bree.de>
	 <E1DQqQ0-0002PB-00@dorka.pomaz.szeredi.hu> <1114623598.4480.181.camel@localhost>
Message-Id: <E1DQqdW-0002SN-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Wed, 27 Apr 2005 19:47:46 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> I think you need to disallow overmounts on invisible mounts by any user
> other than the owner. If not, some other user (including root) can
> overmount on your mount and the user will end up with DoS.

I'm not following you here.  How would an overmount cause DoS?

Thanks,
Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261918AbVD0Ryt@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261918AbVD0Ryt (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 27 Apr 2005 13:54:49 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261857AbVD0RxK
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 27 Apr 2005 13:53:10 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:31141 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S261867AbVD0Rwh (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Apr 2005 13:52:37 -0400
To: lmb@suse.de
CC: mj@ucw.cz, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
In-reply-to: <20050427174641.GZ4431@marowsky-bree.de> (message from Lars
	Marowsky-Bree on Wed, 27 Apr 2005 19:46:41 +0200)
Subject: Re: [PATCH] private mounts
References: <E1DQQ73-0000Zv-00@dorka.pomaz.szeredi.hu> <20050426201411.GA20109@elf.ucw.cz> <E1DQiEa-0001hi-00@dorka.pomaz.szeredi.hu> <20050427092450.GB1819@elf.ucw.cz> <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu> <20050427143126.GB1957@mail.shareable.org> <E1DQno0-00029a-00@dorka.pomaz.szeredi.hu> <20050427153320.GA19065@atrey.karlin.mff.cuni.cz> <20050427155022.GR4431@marowsky-bree.de> <E1DQqQ0-0002PB-00@dorka.pomaz.szeredi.hu> <20050427174641.GZ4431@marowsky-bree.de>
Message-Id: <E1DQqi1-0002T3-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Wed, 27 Apr 2005 19:52:25 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> > > the ability to change the layout underneath, you might trigger bugs in
> > > root programs: Are they really capable of seeing the same filename
> > > twice, or can you throw them into a deep recursion by simulating
> > > infinitely deep directories/circular hardlinks...?
> > Circular or otherwise hardlinked directories are not allowed since it
> > would not only confuse applications but the VFS as well.
> 
> Right, that you can catch. But can you prevent a user fs module from
> creating an infinitely deep directory structure out of thin air? Do you
> limit the maximum path length / depth?

No. 

> (Sending this privately and not to LKML, because I first wanted to check
> the facts ;-)

OK, CC restored.  You shouldn't be afraid to send to LKML.  It's the
ultimate spam list ;)

> > > Certainly a useful tool for hardening applications, but I can see the
> > > point of not wanting to let unwary applications run into a namespace
> > > controlled by a user. Of course, this is sort-of similar to "find
> > > -xdev", but I'm not sure whether it is not indeed new behaviour.
> > 
> > A trivial DoS against any process entering the userspace filesystem is
> > just not to answer the filesystem request.
> > 
> > So it's not just information leak, but also a fine way to _control_
> > certain behavior of applications.
> 
> Yes. I first thought the check was superfluous, because hey, why
> shouldn't root be able to access everything... But then it struck me
> that that might actually be a good idea for all those reasons. root's
> tools don't expect that the namespace they are traversing is
> _completely_ controlled by a user.

Exactly.

Thanks,
Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261887AbVD0R4r@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261887AbVD0R4r (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 27 Apr 2005 13:56:47 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261862AbVD0RzS
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 27 Apr 2005 13:55:18 -0400
Received: from albireo.ucw.cz ([84.242.65.67]:15746 "EHLO albireo.ucw.cz")
	by vger.kernel.org with ESMTP id S261867AbVD0RyX (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Apr 2005 13:54:23 -0400
Date: Wed, 27 Apr 2005 19:54:25 +0200
From: Martin Mares <mj@ucw.cz>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: lmb@suse.de, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050427175425.GA4241@ucw.cz>
References: <20050426201411.GA20109@elf.ucw.cz> <E1DQiEa-0001hi-00@dorka.pomaz.szeredi.hu> <20050427092450.GB1819@elf.ucw.cz> <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu> <20050427143126.GB1957@mail.shareable.org> <E1DQno0-00029a-00@dorka.pomaz.szeredi.hu> <20050427153320.GA19065@atrey.karlin.mff.cuni.cz> <20050427155022.GR4431@marowsky-bree.de> <20050427164652.GA3129@ucw.cz> <E1DQqUi-0002Pt-00@dorka.pomaz.szeredi.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1DQqUi-0002Pt-00@dorka.pomaz.szeredi.hu>
User-Agent: Mutt/1.3.28i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Miklos!

> Is it possible to limit all these from kernelspace?  Probably yes,
> although a timeout for operations is something that cuts either way.
> And the compexity of these checks would probably be orders of
> magnitude higher then the check we are currently discussing.

Yes ... but does the check we are discussing really solve the problem?

Let's say that you attempt to export home directories of users by a user-space
NFS daemon. This daemon probably changes its fsuid to match the remote user,
so the check happily accepts the access and the user is able to lock up the
daemon.

It doesn't seem that there is any simple and universal cure -- root programs
or setuid programs altering their fsuid are just too similar to the real user
programs to separate them cleanly.

I see a lot of similarities with symlinks -- many programs also need to take
extra care of symlinks to be safe. However, symlinks are already senior
citizens of Unix systems and programs know how to cope with them since ages.

Maybe this could be taken advantage of by keeping all user mounts in a separate
directory like /mnt/usr (and /mnt is very likely to be avoided by all programs
traversing directory structure automatically) and symlinking from the requested
mount points there (with symlinks naturally not followed by automatic traversals).

I agree it isn't a neat solution, but it seems to be the first one which is
close to working.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Lisp Users: Due to the holiday, there will be no garbage collection on Monday.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261888AbVD0R7X@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261888AbVD0R7X (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 27 Apr 2005 13:59:23 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261892AbVD0R5J
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 27 Apr 2005 13:57:09 -0400
Received: from e5.ny.us.ibm.com ([32.97.182.145]:30122 "EHLO e5.ny.us.ibm.com")
	by vger.kernel.org with ESMTP id S261852AbVD0Rzs (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Apr 2005 13:55:48 -0400
Subject: Re: [PATCH] private mounts
From: Ram <linuxram@us.ibm.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: lmb@suse.de, mj@ucw.cz, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org
In-Reply-To: <E1DQqdW-0002SN-00@dorka.pomaz.szeredi.hu>
References: <20050426094727.GA30379@infradead.org>
	 <20050426131943.GC2226@openzaurus.ucw.cz>
	 <E1DQQ73-0000Zv-00@dorka.pomaz.szeredi.hu>
	 <20050426201411.GA20109@elf.ucw.cz>
	 <E1DQiEa-0001hi-00@dorka.pomaz.szeredi.hu>
	 <20050427092450.GB1819@elf.ucw.cz>
	 <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu>
	 <20050427143126.GB1957@mail.shareable.org>
	 <E1DQno0-00029a-00@dorka.pomaz.szeredi.hu>
	 <20050427153320.GA19065@atrey.karlin.mff.cuni.cz>
	 <20050427155022.GR4431@marowsky-bree.de>
	 <E1DQqQ0-0002PB-00@dorka.pomaz.szeredi.hu>
	 <1114623598.4480.181.camel@localhost>
	 <E1DQqdW-0002SN-00@dorka.pomaz.szeredi.hu>
Content-Type: text/plain
Organization: IBM 
Message-Id: <1114624541.4480.187.camel@localhost>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 
Date: Wed, 27 Apr 2005 10:55:41 -0700
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, 2005-04-27 at 10:47, Miklos Szeredi wrote:
> > I think you need to disallow overmounts on invisible mounts by any user
> > other than the owner. If not, some other user (including root) can
> > overmount on your mount and the user will end up with DoS.
> 
> I'm not following you here.  How would an overmount cause DoS?

eg:
 
user 1 does a invisible mount on /mnt/mnt1
root does a visible mount on /mnt/mnt1

user 1 will no longer be able to access his /mnt/mnt1

in fact even if root mounts something on /mnt, the problem still exists.

RP

> 
> Thanks,
> Miklos


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261928AbVD0SJu@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261928AbVD0SJu (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 27 Apr 2005 14:09:50 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261915AbVD0SJa
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 27 Apr 2005 14:09:30 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:38821 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S261892AbVD0SFe (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Apr 2005 14:05:34 -0400
To: mj@ucw.cz
CC: lmb@suse.de, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
In-reply-to: <20050427175425.GA4241@ucw.cz> (message from Martin Mares on Wed,
	27 Apr 2005 19:54:25 +0200)
Subject: Re: [PATCH] private mounts
References: <20050426201411.GA20109@elf.ucw.cz> <E1DQiEa-0001hi-00@dorka.pomaz.szeredi.hu> <20050427092450.GB1819@elf.ucw.cz> <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu> <20050427143126.GB1957@mail.shareable.org> <E1DQno0-00029a-00@dorka.pomaz.szeredi.hu> <20050427153320.GA19065@atrey.karlin.mff.cuni.cz> <20050427155022.GR4431@marowsky-bree.de> <20050427164652.GA3129@ucw.cz> <E1DQqUi-0002Pt-00@dorka.pomaz.szeredi.hu> <20050427175425.GA4241@ucw.cz>
Message-Id: <E1DQquc-0002W6-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Wed, 27 Apr 2005 20:05:26 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> > Is it possible to limit all these from kernelspace?  Probably yes,
> > although a timeout for operations is something that cuts either way.
> > And the compexity of these checks would probably be orders of
> > magnitude higher then the check we are currently discussing.
> 
> Yes ... but does the check we are discussing really solve the
> problem?
> 
> Let's say that you attempt to export home directories of users by a
> user-space NFS daemon. This daemon probably changes its fsuid to
> match the remote user, so the check happily accepts the access and
> the user is able to lock up the daemon.

Valid point.  The only defense is that when a program set's fsuid,
it's performing the operation "on behalf of the user".  So the user is
actually doing DoS against himself.

Of course this is not strictly true.  E.g. in the userspace NFS case
it's probably a DoS against all users of the mount.

> It doesn't seem that there is any simple and universal cure -- root
> programs or setuid programs altering their fsuid are just too
> similar to the real user programs to separate them cleanly.

Root programs setting fsuid are relatively rare, most are suid
programs originally started from the user (nfsd is an exception).

So yes the check fsuid is not the perfect solution.  However let me
remind you that neither is the one with private namespace.

> I see a lot of similarities with symlinks -- many programs also need
> to take extra care of symlinks to be safe. However, symlinks are
> already senior citizens of Unix systems and programs know how to
> cope with them since ages.
> 
> Maybe this could be taken advantage of by keeping all user mounts in
> a separate directory like /mnt/usr (and /mnt is very likely to be
> avoided by all programs traversing directory structure
> automatically) and symlinking from the requested mount points there
> (with symlinks naturally not followed by automatic traversals).

Maybe.  It would be trivial to add a config option to fuse.conf to
limit user mounts to some directory.

Thanks,
Miklos




From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261892AbVD0SM2@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261892AbVD0SM2 (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 27 Apr 2005 14:12:28 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261914AbVD0SKO
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 27 Apr 2005 14:10:14 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:39845 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S261927AbVD0SJr (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Apr 2005 14:09:47 -0400
To: linuxram@us.ibm.com
CC: lmb@suse.de, mj@ucw.cz, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org
In-reply-to: <1114624541.4480.187.camel@localhost> (message from Ram on Wed,
	27 Apr 2005 10:55:41 -0700)
Subject: Re: [PATCH] private mounts
References: <20050426094727.GA30379@infradead.org>
	 <20050426131943.GC2226@openzaurus.ucw.cz>
	 <E1DQQ73-0000Zv-00@dorka.pomaz.szeredi.hu>
	 <20050426201411.GA20109@elf.ucw.cz>
	 <E1DQiEa-0001hi-00@dorka.pomaz.szeredi.hu>
	 <20050427092450.GB1819@elf.ucw.cz>
	 <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu>
	 <20050427143126.GB1957@mail.shareable.org>
	 <E1DQno0-00029a-00@dorka.pomaz.szeredi.hu>
	 <20050427153320.GA19065@atrey.karlin.mff.cuni.cz>
	 <20050427155022.GR4431@marowsky-bree.de>
	 <E1DQqQ0-0002PB-00@dorka.pomaz.szeredi.hu>
	 <1114623598.4480.181.camel@localhost>
	 <E1DQqdW-0002SN-00@dorka.pomaz.szeredi.hu> <1114624541.4480.187.camel@localhost>
Message-Id: <E1DQqyY-0002WW-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Wed, 27 Apr 2005 20:09:30 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> eg:
>  
> user 1 does a invisible mount on /mnt/mnt1
> root does a visible mount on /mnt/mnt1
> 
> user 1 will no longer be able to access his /mnt/mnt1
> 
> in fact even if root mounts something on /mnt, the problem still exists.

This is not something specific to FUSE.  Root can overmount any of
your directories after which you won't be able to access it (unless
some of your processes have a CWD there).

Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261934AbVD0S0N@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261934AbVD0S0N (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 27 Apr 2005 14:26:13 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261938AbVD0S0A
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 27 Apr 2005 14:26:00 -0400
Received: from albireo.ucw.cz ([84.242.65.67]:28546 "EHLO albireo.ucw.cz")
	by vger.kernel.org with ESMTP id S261934AbVD0SZb (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Apr 2005 14:25:31 -0400
Date: Wed, 27 Apr 2005 20:25:28 +0200
From: Martin Mares <mj@ucw.cz>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: lmb@suse.de, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050427182528.GD4241@ucw.cz>
References: <20050427092450.GB1819@elf.ucw.cz> <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu> <20050427143126.GB1957@mail.shareable.org> <E1DQno0-00029a-00@dorka.pomaz.szeredi.hu> <20050427153320.GA19065@atrey.karlin.mff.cuni.cz> <20050427155022.GR4431@marowsky-bree.de> <20050427164652.GA3129@ucw.cz> <E1DQqUi-0002Pt-00@dorka.pomaz.szeredi.hu> <20050427175425.GA4241@ucw.cz> <E1DQquc-0002W6-00@dorka.pomaz.szeredi.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1DQquc-0002W6-00@dorka.pomaz.szeredi.hu>
User-Agent: Mutt/1.3.28i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Hello!

> So yes the check fsuid is not the perfect solution.  However let me
> remind you that neither is the one with private namespace.

What I'm arguing about is that the fsuid check is obscure (it breaks
traditional semantics of file permissions [*], it doesn't allow an user
to grant access to his user mount to other users, even if the permissions
allow that and so on) and it doesn't fully solve the problem anyway.

For similar reasons, I don't advocate for private namespaces either.

The cure more likely lies in simple policy rules like the "all user mounts
belong to /mnt/usr" one, instead of putting dubious policy to the kernel.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Mr. Worf, scan that ship."  "Aye, Captain... 600 DPI?

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261955AbVD0Srt@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261955AbVD0Srt (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 27 Apr 2005 14:47:49 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261951AbVD0Spf
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 27 Apr 2005 14:45:35 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:51109 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S261946AbVD0SnX (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Apr 2005 14:43:23 -0400
To: mj@ucw.cz
CC: lmb@suse.de, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
In-reply-to: <20050427182528.GD4241@ucw.cz> (message from Martin Mares on Wed,
	27 Apr 2005 20:25:28 +0200)
Subject: Re: [PATCH] private mounts
References: <20050427092450.GB1819@elf.ucw.cz> <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu> <20050427143126.GB1957@mail.shareable.org> <E1DQno0-00029a-00@dorka.pomaz.szeredi.hu> <20050427153320.GA19065@atrey.karlin.mff.cuni.cz> <20050427155022.GR4431@marowsky-bree.de> <20050427164652.GA3129@ucw.cz> <E1DQqUi-0002Pt-00@dorka.pomaz.szeredi.hu> <20050427175425.GA4241@ucw.cz> <E1DQquc-0002W6-00@dorka.pomaz.szeredi.hu> <20050427182528.GD4241@ucw.cz>
Message-Id: <E1DQrUr-0003MI-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Wed, 27 Apr 2005 20:42:53 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> > So yes the check fsuid is not the perfect solution.  However let me
> > remind you that neither is the one with private namespace.
> 
> What I'm arguing about is that the fsuid check is obscure (it breaks
> traditional semantics of file permissions [*],

No, the permissions are not visible to any other user.  So there are
no semantics to break.

> it doesn't allow an user to grant access to his user mount to other
> users,

Yes, but that granting must be explicitly acknowledget by the grantee,
to avoid the problems previously discussed.  It's probably something
possible to do with the private namespaces (sending mounts to other
user's namespaces, etc)

> even if the permissions allow that and so on) and it doesn't
> fully solve the problem anyway.

I think I know how to fully solve the problem.  If the user has
permission to ptrace the process in question then he can already do
whatever he likes with that process, so userspace filesystem operation
can unconditionally be allowed.  Otherwise it's no-no by default.

This thread is proving to be ever more useful :)  Thanks everyone!

> For similar reasons, I don't advocate for private namespaces either.
> 
> The cure more likely lies in simple policy rules like the "all user mounts
> belong to /mnt/usr" one, instead of putting dubious policy to the kernel.

I'm keeping policy out of the kernel by making the check optional.
Then the userspace daemon can enforce such policies as /mnt/usr.

I'll prefer the checking one, since, I'm all alone on my machine,
don't want to share anything, but _do_ want to have mounts under my
home directory.  You prefer the /mnt/usr, since you want to share it
with others.  A combination is also possible: the user choses for each
mount which is preferable.

Agreed?

Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261979AbVD0Tk3@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261979AbVD0Tk3 (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 27 Apr 2005 15:40:29 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261977AbVD0Tk2
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 27 Apr 2005 15:40:28 -0400
Received: from e31.co.us.ibm.com ([32.97.110.129]:30412 "EHLO
	e31.co.us.ibm.com") by vger.kernel.org with ESMTP id S261978AbVD0TkO
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Apr 2005 15:40:14 -0400
Subject: Re: [PATCH] private mounts
From: Ram <linuxram@us.ibm.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: lmb@suse.de, mj@ucw.cz, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org
In-Reply-To: <E1DQqyY-0002WW-00@dorka.pomaz.szeredi.hu>
References: <20050426094727.GA30379@infradead.org>
	 <20050426131943.GC2226@openzaurus.ucw.cz>
	 <E1DQQ73-0000Zv-00@dorka.pomaz.szeredi.hu>
	 <20050426201411.GA20109@elf.ucw.cz>
	 <E1DQiEa-0001hi-00@dorka.pomaz.szeredi.hu>
	 <20050427092450.GB1819@elf.ucw.cz>
	 <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu>
	 <20050427143126.GB1957@mail.shareable.org>
	 <E1DQno0-00029a-00@dorka.pomaz.szeredi.hu>
	 <20050427153320.GA19065@atrey.karlin.mff.cuni.cz>
	 <20050427155022.GR4431@marowsky-bree.de>
	 <E1DQqQ0-0002PB-00@dorka.pomaz.szeredi.hu>
	 <1114623598.4480.181.camel@localhost>
	 <E1DQqdW-0002SN-00@dorka.pomaz.szeredi.hu>
	 <1114624541.4480.187.camel@localhost>
	 <E1DQqyY-0002WW-00@dorka.pomaz.szeredi.hu>
Content-Type: text/plain
Organization: IBM 
Message-Id: <1114630811.4180.20.camel@localhost>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 
Date: Wed, 27 Apr 2005 12:40:12 -0700
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, 2005-04-27 at 11:09, Miklos Szeredi wrote:
> > eg:
> >  
> > user 1 does a invisible mount on /mnt/mnt1
> > root does a visible mount on /mnt/mnt1
> > 
> > user 1 will no longer be able to access his /mnt/mnt1
> > 
> > in fact even if root mounts something on /mnt, the problem still exists.
> 
> This is not something specific to FUSE.  Root can overmount any of
> your directories after which you won't be able to access it (unless
> some of your processes have a CWD there).

sorry, I think I have not raised by concern clearly.

I am mostly talking about the semantics of 'invisible/private mount' not
FUSE in particular, since the kernel patch brings in new feature
to VFS.

My understanding of private mount is:
1. The contents of the private mount is visible only to the 
    mount owner.
2. The vfsmount of the private mount is only accessible to
   the mount owner, and only the mount owner can mount anything
   on top of it.

But I dont see (2) is being checked for.

I can overmount something on top of a private mount owned by someother
user. I verified that with your patch.

1. do a invisible mount as user 'x' on /mnt
2. do a visible mount as root on /mnt  and it *succeeds* and also masks
    the earlier mount to the user 'x'.

I am not concerned about the masking effect so much. But I am concerned
that the private vfsmount at /mnt is accessible to someother user 
to mount something else on top of it. **The dentry on top of which  the
new vfsmount is done belongs to the private vfsmount**.


Am I making sense? If I do make sense, than all we need is a patch on
top of your patch which disallows non-owner to mount something on top of
a private/invisible vfsmount owned by some owner.

If I am not making sense, I keep quite :)
RP



> 
> Miklos


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261988AbVD0UEI@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261988AbVD0UEI (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 27 Apr 2005 16:04:08 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261991AbVD0UEI
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 27 Apr 2005 16:04:08 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:8870 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S261988AbVD0UD6 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Apr 2005 16:03:58 -0400
To: linuxram@us.ibm.com
CC: lmb@suse.de, mj@ucw.cz, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org
In-reply-to: <1114630811.4180.20.camel@localhost> (message from Ram on Wed, 27
	Apr 2005 12:40:12 -0700)
Subject: Re: [PATCH] private mounts
References: <20050426094727.GA30379@infradead.org>
	 <20050426131943.GC2226@openzaurus.ucw.cz>
	 <E1DQQ73-0000Zv-00@dorka.pomaz.szeredi.hu>
	 <20050426201411.GA20109@elf.ucw.cz>
	 <E1DQiEa-0001hi-00@dorka.pomaz.szeredi.hu>
	 <20050427092450.GB1819@elf.ucw.cz>
	 <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu>
	 <20050427143126.GB1957@mail.shareable.org>
	 <E1DQno0-00029a-00@dorka.pomaz.szeredi.hu>
	 <20050427153320.GA19065@atrey.karlin.mff.cuni.cz>
	 <20050427155022.GR4431@marowsky-bree.de>
	 <E1DQqQ0-0002PB-00@dorka.pomaz.szeredi.hu>
	 <1114623598.4480.181.camel@localhost>
	 <E1DQqdW-0002SN-00@dorka.pomaz.szeredi.hu>
	 <1114624541.4480.187.camel@localhost>
	 <E1DQqyY-0002WW-00@dorka.pomaz.szeredi.hu> <1114630811.4180.20.camel@localhost>
Message-Id: <E1DQskk-0004dI-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Wed, 27 Apr 2005 22:03:22 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> sorry, I think I have not raised by concern clearly.
> 
> I am mostly talking about the semantics of 'invisible/private mount' not
> FUSE in particular, since the kernel patch brings in new feature
> to VFS.
> 
> My understanding of private mount is:
> 1. The contents of the private mount is visible only to the 
>     mount owner.
> 2. The vfsmount of the private mount is only accessible to
>    the mount owner, and only the mount owner can mount anything
>    on top of it.
> 
> But I dont see (2) is being checked for.

It's automatically enforced, since the mount syscall itself will use
the same path lookup mechanism as any other filesystem operation.

> I can overmount something on top of a private mount owned by someother
> user. I verified that with your patch.
> 
> 1. do a invisible mount as user 'x' on /mnt
> 2. do a visible mount as root on /mnt  and it *succeeds* and also masks
>     the earlier mount to the user 'x'.

Yes, because a later mount on a _same_ dentry will mask an earlier
mount.  But that does not mean, that the mount happened on the private
mount's root.

You can check where the mount ended up, by having a shell of 'x' cd to
the private mount.  Then do the overmount.  If the shell can still see
the private mount, then the overmount did not in fact mount over the
private root.

> Am I making sense? If I do make sense, than all we need is a patch on
> top of your patch which disallows non-owner to mount something on top of
> a private/invisible vfsmount owned by some owner.

Yes it makes sense, but I think what you want is already the case.

Thanks,
Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262013AbVD0U4E@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262013AbVD0U4E (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 27 Apr 2005 16:56:04 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262012AbVD0U4D
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 27 Apr 2005 16:56:03 -0400
Received: from prgy-npn1.prodigy.com ([207.115.54.37]:44942 "EHLO
	oddball.prodigy.com") by vger.kernel.org with ESMTP id S262010AbVD0Uzl
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Apr 2005 16:55:41 -0400
Message-ID: <426FFC30.1060700@tmr.com>
Date: Wed, 27 Apr 2005 16:55:12 -0400
From: Bill Davidsen <davidsen@tmr.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050319
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ram <linuxram@us.ibm.com>
CC: Miklos Szeredi <miklos@szeredi.hu>, lmb@suse.de, mj@ucw.cz,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] private mounts
References: <E1DQqyY-0002WW-00@dorka.pomaz.szeredi.hu><20050426094727.GA30379@infradead.org> <1114630811.4180.20.camel@localhost>
In-Reply-To: <1114630811.4180.20.camel@localhost>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Ram wrote:
> On Wed, 2005-04-27 at 11:09, Miklos Szeredi wrote:
> 
>>>eg:
>>> 
>>>user 1 does a invisible mount on /mnt/mnt1
>>>root does a visible mount on /mnt/mnt1
>>>
>>>user 1 will no longer be able to access his /mnt/mnt1
>>>
>>>in fact even if root mounts something on /mnt, the problem still exists.
>>
>>This is not something specific to FUSE.  Root can overmount any of
>>your directories after which you won't be able to access it (unless
>>some of your processes have a CWD there).
> 
> 
> sorry, I think I have not raised by concern clearly.
> 
> I am mostly talking about the semantics of 'invisible/private mount' not
> FUSE in particular, since the kernel patch brings in new feature
> to VFS.
> 
> My understanding of private mount is:
> 1. The contents of the private mount is visible only to the 
>     mount owner.
> 2. The vfsmount of the private mount is only accessible to
>    the mount owner, and only the mount owner can mount anything
>    on top of it.
> 
> But I dont see (2) is being checked for.
> 
> I can overmount something on top of a private mount owned by someother
> user. I verified that with your patch.
> 
> 1. do a invisible mount as user 'x' on /mnt
> 2. do a visible mount as root on /mnt  and it *succeeds* and also masks
>     the earlier mount to the user 'x'.
> 
> I am not concerned about the masking effect so much. But I am concerned
> that the private vfsmount at /mnt is accessible to someother user 
> to mount something else on top of it. **The dentry on top of which  the
> new vfsmount is done belongs to the private vfsmount**.
> 
> 
> Am I making sense? If I do make sense, than all we need is a patch on
> top of your patch which disallows non-owner to mount something on top of
> a private/invisible vfsmount owned by some owner.
> 
> If I am not making sense, I keep quite :)

I think you point out a solution could be worse that what it cures. 
There are clearly problems with mount over, but imagine that a user does 
an invisible mount over /mnt, doesn't that prevent other mounts which 
are usually made, like /mnt/cdrom, /mnt/loopN, etc?

Every time someone suggests a solution it seems to open a new path to 
possible abuse. And features which only work with a monotonic kernel 
rather than modules would seem to indicate that the feature is nice but 
the implementation might benefit from more thinking time.

Frankly the whole statement that the controversial code MUST go in now 
and could be removed later sounds like a salesman telling me I MUST sign 
the contract today, but he will let me out of it if I decide it was a 
mistake.

I'm not against the feature, but a lot of people I consider competent 
seem to find the implementation controversial, which argues for waiting 
until more eyes are on the code. If the rest of the code is useless 
without the controversial part, maybe it should all stay a patch to use 
or not as people decide.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262035AbVD0Vij@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262035AbVD0Vij (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 27 Apr 2005 17:38:39 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262040AbVD0Vii
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 27 Apr 2005 17:38:38 -0400
Received: from e6.ny.us.ibm.com ([32.97.182.146]:23436 "EHLO e6.ny.us.ibm.com")
	by vger.kernel.org with ESMTP id S262035AbVD0ViR (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Apr 2005 17:38:17 -0400
Subject: Re: [PATCH] private mounts
From: Ram <linuxram@us.ibm.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: lmb@suse.de, mj@ucw.cz, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org
In-Reply-To: <E1DQskk-0004dI-00@dorka.pomaz.szeredi.hu>
References: <20050426094727.GA30379@infradead.org>
	 <20050426131943.GC2226@openzaurus.ucw.cz>
	 <E1DQQ73-0000Zv-00@dorka.pomaz.szeredi.hu>
	 <20050426201411.GA20109@elf.ucw.cz>
	 <E1DQiEa-0001hi-00@dorka.pomaz.szeredi.hu>
	 <20050427092450.GB1819@elf.ucw.cz>
	 <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu>
	 <20050427143126.GB1957@mail.shareable.org>
	 <E1DQno0-00029a-00@dorka.pomaz.szeredi.hu>
	 <20050427153320.GA19065@atrey.karlin.mff.cuni.cz>
	 <20050427155022.GR4431@marowsky-bree.de>
	 <E1DQqQ0-0002PB-00@dorka.pomaz.szeredi.hu>
	 <1114623598.4480.181.camel@localhost>
	 <E1DQqdW-0002SN-00@dorka.pomaz.szeredi.hu>
	 <1114624541.4480.187.camel@localhost>
	 <E1DQqyY-0002WW-00@dorka.pomaz.szeredi.hu>
	 <1114630811.4180.20.camel@localhost>
	 <E1DQskk-0004dI-00@dorka.pomaz.szeredi.hu>
Content-Type: text/plain
Organization: IBM 
Message-Id: <1114637883.4180.55.camel@localhost>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 
Date: Wed, 27 Apr 2005 14:38:03 -0700
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, 2005-04-27 at 13:03, Miklos Szeredi wrote:
> > sorry, I think I have not raised by concern clearly.
> > 
> > I am mostly talking about the semantics of 'invisible/private mount' not
> > FUSE in particular, since the kernel patch brings in new feature
> > to VFS.
> > 
> > My understanding of private mount is:
> > 1. The contents of the private mount is visible only to the 
> >     mount owner.
> > 2. The vfsmount of the private mount is only accessible to
> >    the mount owner, and only the mount owner can mount anything
> >    on top of it.
> > 
> > But I dont see (2) is being checked for.
> 
> It's automatically enforced, since the mount syscall itself will use
> the same path lookup mechanism as any other filesystem operation.
> 
> > I can overmount something on top of a private mount owned by someother
> > user. I verified that with your patch.
> > 
> > 1. do a invisible mount as user 'x' on /mnt
> > 2. do a visible mount as root on /mnt  and it *succeeds* and also masks
> >     the earlier mount to the user 'x'.
> 
> Yes, because a later mount on a _same_ dentry will mask an earlier
> mount.  But that does not mean, that the mount happened on the private
> mount's root.
> 
> You can check where the mount ended up, by having a shell of 'x' cd to
> the private mount.  Then do the overmount.  If the shell can still see
> the private mount, then the overmount did not in fact mount over the
> private root.

ok. Generally overmounts are done on the root dentry of the topmost
vfsmount.  But in this case, your patch mounts it on the same dentry
as that of the private mount.

Essentially I was always under the assertion that 'a dentry can hold
only one vfsmount'.  But invisible mount seem to invalidate that
assertion.  Don't see any bad effects of that.  Probably some VFS
experts may. (or probably my assertion is wrong to begin with)

RP



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262076AbVD0XAH@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262076AbVD0XAH (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 27 Apr 2005 19:00:07 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262077AbVD0XAH
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 27 Apr 2005 19:00:07 -0400
Received: from gprs189-60.eurotel.cz ([160.218.189.60]:33450 "EHLO amd.ucw.cz")
	by vger.kernel.org with ESMTP id S262076AbVD0W7z (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Apr 2005 18:59:55 -0400
Date: Wed, 27 Apr 2005 16:58:42 +0200
From: Pavel Machek <pavel@ucw.cz>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: bulb@ucw.cz, hch@infradead.org, jamie@shareable.org, linuxram@us.ibm.com,
       7eggert@gmx.de, viro@parcelfarce.linux.theplanet.co.uk,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050427145842.GD28119@elf.ucw.cz>
References: <20050426131943.GC2226@openzaurus.ucw.cz> <E1DQQ73-0000Zv-00@dorka.pomaz.szeredi.hu> <20050426201411.GA20109@elf.ucw.cz> <E1DQiEa-0001hi-00@dorka.pomaz.szeredi.hu> <20050427092450.GB1819@elf.ucw.cz> <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu> <20050427115754.GA8981@vagabond> <E1DQla0-0001vG-00@dorka.pomaz.szeredi.hu> <20050427123944.GA11020@vagabond> <E1DQmUm-0001yy-00@dorka.pomaz.szeredi.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1DQmUm-0001yy-00@dorka.pomaz.szeredi.hu>
X-Warning: Reading this can be dangerous to your mental health.
User-Agent: Mutt/1.5.6+20040907i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Hi!

> > The userland tools don't need to know. They just need to not be suid.
> 
> But I'd want to continue distribute the non-crippled kernel module
> too, with suid fusermount.  Then fusermount _has_ to know which kernel
> module is currently active.

Add a mount flag and make kernel refuse mount on unknown flags?

> > Ok, here I say it is ugly (but not that it's crap). And the reason is,
> > that there is a permission system, with some semantics, and then various
> > filesystems adapt it in varous ways to fit what they want. So every
> > filesystem ends up with it's onw little different behaviour.
> > 
> > That being said, fuse does just about the same as NFS, samba and others
> > and I don't really see the reason why it couldn't be integrated. But
> > I am not the one to decide.
> 
> Every opinion counts.
> 
> I'm not trying to convince people that the current solution is
> perfect.  What I'm saying that it's
> 
>   a) not harmful
> 
>   b) it makes non-privileged mounts possible
> 
> And b) is _the_ most important feature IMO, so the argument for
> stripping it out has to be very good.

Well, you'll have problems with suid programs suddenly not being able
to access files. nfs gets away with it, but nfs is perceived as
"broken" anyway...

								Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262096AbVD0XWV@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262096AbVD0XWV (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 27 Apr 2005 19:22:21 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262094AbVD0XWV
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 27 Apr 2005 19:22:21 -0400
Received: from pat.uio.no ([129.240.130.16]:42138 "EHLO pat.uio.no")
	by vger.kernel.org with ESMTP id S262093AbVD0XWP (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Apr 2005 19:22:15 -0400
Subject: Re: [PATCH] private mounts
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Pavel Machek <pavel@ucw.cz>
Cc: Miklos Szeredi <miklos@szeredi.hu>, bulb@ucw.cz, hch@infradead.org,
       jamie@shareable.org, linuxram@us.ibm.com, 7eggert@gmx.de,
       Alexander Viro <viro@parcelfarce.linux.theplanet.co.uk>,
       Linux Filesystem Development <linux-fsdevel@vger.kernel.org>,
       linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>
In-Reply-To: <20050427145842.GD28119@elf.ucw.cz>
References: <20050426131943.GC2226@openzaurus.ucw.cz>
	 <E1DQQ73-0000Zv-00@dorka.pomaz.szeredi.hu>
	 <20050426201411.GA20109@elf.ucw.cz>
	 <E1DQiEa-0001hi-00@dorka.pomaz.szeredi.hu>
	 <20050427092450.GB1819@elf.ucw.cz>
	 <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu> <20050427115754.GA8981@vagabond>
	 <E1DQla0-0001vG-00@dorka.pomaz.szeredi.hu>
	 <20050427123944.GA11020@vagabond>
	 <E1DQmUm-0001yy-00@dorka.pomaz.szeredi.hu>
	 <20050427145842.GD28119@elf.ucw.cz>
Content-Type: text/plain
Date: Wed, 27 Apr 2005 19:21:56 -0400
Message-Id: <1114644116.9947.14.camel@lade.trondhjem.org>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.864, required 12,
	autolearn=disabled, AWL 1.14, UIO_MAIL_IS_INTERNAL -5.00)
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

on den 27.04.2005 Klokka 16:58 (+0200) skreiv Pavel Machek:

> > 
> > And b) is _the_ most important feature IMO, so the argument for
> > stripping it out has to be very good.
> 
> Well, you'll have problems with suid programs suddenly not being able
> to access files. nfs gets away with it, but nfs is perceived as
> "broken" anyway...

Really?

The NFS security model is based on the principle that the administrator
of the SERVER can override access permissions on his/her hardware. Pray
tell why you think that is "broken"?

Cheers,
  Trond

-- 
Trond Myklebust <trond.myklebust@fys.uio.no>


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261856AbVD1HDn@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261856AbVD1HDn (ORCPT <rfc822;willy@w.ods.org>);
	Thu, 28 Apr 2005 03:03:43 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261853AbVD1HDI
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 28 Apr 2005 03:03:08 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:53671 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S261856AbVD1HBl (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 28 Apr 2005 03:01:41 -0400
To: linuxram@us.ibm.com
CC: miklos@szeredi.hu, lmb@suse.de, mj@ucw.cz, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org
In-reply-to: <1114637883.4180.55.camel@localhost> (message from Ram on Wed, 27
	Apr 2005 14:38:03 -0700)
Subject: Re: [PATCH] private mounts
References: <20050426094727.GA30379@infradead.org>
	 <20050426131943.GC2226@openzaurus.ucw.cz>
	 <E1DQQ73-0000Zv-00@dorka.pomaz.szeredi.hu>
	 <20050426201411.GA20109@elf.ucw.cz>
	 <E1DQiEa-0001hi-00@dorka.pomaz.szeredi.hu>
	 <20050427092450.GB1819@elf.ucw.cz>
	 <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu>
	 <20050427143126.GB1957@mail.shareable.org>
	 <E1DQno0-00029a-00@dorka.pomaz.szeredi.hu>
	 <20050427153320.GA19065@atrey.karlin.mff.cuni.cz>
	 <20050427155022.GR4431@marowsky-bree.de>
	 <E1DQqQ0-0002PB-00@dorka.pomaz.szeredi.hu>
	 <1114623598.4480.181.camel@localhost>
	 <E1DQqdW-0002SN-00@dorka.pomaz.szeredi.hu>
	 <1114624541.4480.187.camel@localhost>
	 <E1DQqyY-0002WW-00@dorka.pomaz.szeredi.hu>
	 <1114630811.4180.20.camel@localhost>
	 <E1DQskk-0004dI-00@dorka.pomaz.szeredi.hu> <1114637883.4180.55.camel@localhost>
Message-Id: <E1DR312-0005IZ-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Thu, 28 Apr 2005 09:00:52 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> ok. Generally overmounts are done on the root dentry of the topmost
> vfsmount.  But in this case, your patch mounts it on the same dentry
> as that of the private mount.
> 
> Essentially I was always under the assertion that 'a dentry can hold
> only one vfsmount'.  But invisible mount seem to invalidate that
> assertion.

You can do that without an invisible mount:

mkdir /tmp/mnt
mkdir /tmp/dir1
mkdir /tmp/dir1/subdir1
mkdir /tmp/dir2
mkdir /tmp/dir2/subdir2

cd /tmp/mnt
mount --bind /tmp/dir1 .
mount --bind /tmp/dir2 .

Now you have both /tmp/dir1 and /tmp/dir2 rooted at the same dentry.

To test this, in another shell do this just after the first bind mount:

cd /tmp/mnt

Then after the second mount do

ls -l subdir1/..

Now unmount everything and repeat the experiment, but do the mounts
this way:

mount --bind /tmp/dir1 /tmp/mnt
mount --bind /tmp/dir2 /tmp/mnt

Now the second mount is an overmount of the first, and you will
actually get different result from the "ls".

Playing with mounts is fun :)

Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261911AbVD1HZw@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261911AbVD1HZw (ORCPT <rfc822;willy@w.ods.org>);
	Thu, 28 Apr 2005 03:25:52 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261772AbVD1HZw
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 28 Apr 2005 03:25:52 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:61607 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S261329AbVD1HYZ (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 28 Apr 2005 03:24:25 -0400
To: davidsen@tmr.com
CC: linuxram@us.ibm.com, lmb@suse.de, mj@ucw.cz, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org
In-reply-to: <426FFC30.1060700@tmr.com> (message from Bill Davidsen on Wed, 27
	Apr 2005 16:55:12 -0400)
Subject: Re: [PATCH] private mounts
References: <E1DQqyY-0002WW-00@dorka.pomaz.szeredi.hu><20050426094727.GA30379@infradead.org> <1114630811.4180.20.camel@localhost> <426FFC30.1060700@tmr.com>
Message-Id: <E1DR3NT-0005L0-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Thu, 28 Apr 2005 09:24:03 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> I think you point out a solution could be worse that what it cures. 
> There are clearly problems with mount over, but imagine that a user does 
> an invisible mount over /mnt, doesn't that prevent other mounts which 
> are usually made, like /mnt/cdrom, /mnt/loopN, etc?

As previously explained, user mounts are only allowed on directories
for which the user has full write access.  Exactly for this reason.

> Every time someone suggests a solution it seems to open a new path to 
> possible abuse. And features which only work with a monotonic kernel 
> rather than modules would seem to indicate that the feature is nice but 
> the implementation might benefit from more thinking time.

Huh?  Where did modularitly come into this?

> Frankly the whole statement that the controversial code MUST go in now 
> and could be removed later sounds like a salesman telling me I MUST sign 
> the contract today, but he will let me out of it if I decide it was a 
> mistake.

The point of this thread is to find a solution to a problem.  The
discussion is turning up very interesting viewpoints and I'm
understanding the problem better and better, and I think other people
are too.

While I disagree with the view taken by Christoph H., I'm now also
thankful to him for stiring up the mud, because it ended up with a lot
of useful ideas.

In the end I'd like a solution that everybody is happy with.  That
means I'm not going to give up searching because someone said, that
the current solution is crappy.

Do you understand my position?

> I'm not against the feature, but a lot of people I consider competent 
> seem to find the implementation controversial, which argues for waiting 
> until more eyes are on the code.

Yes.  I'm not going to ask Andrew to merge the code until I feel that
everybody concerned is happy with it.  No matter how many release
cycles it takes.

> If the rest of the code is useless without the controversial part,
> maybe it should all stay a patch to use or not as people decide.

It has been distributed separately from the kernel for 3 years now.
So people _can_ try it out.

Thanks,
Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261740AbVD1IkF@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261740AbVD1IkF (ORCPT <rfc822;willy@w.ods.org>);
	Thu, 28 Apr 2005 04:40:05 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261937AbVD1IhA
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 28 Apr 2005 04:37:00 -0400
Received: from gprs189-60.eurotel.cz ([160.218.189.60]:22215 "EHLO amd.ucw.cz")
	by vger.kernel.org with ESMTP id S261898AbVD1IZG (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 28 Apr 2005 04:25:06 -0400
Date: Thu, 28 Apr 2005 10:24:44 +0200
From: Pavel Machek <pavel@ucw.cz>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Miklos Szeredi <miklos@szeredi.hu>, bulb@ucw.cz, hch@infradead.org,
       jamie@shareable.org, linuxram@us.ibm.com, 7eggert@gmx.de,
       Alexander Viro <viro@parcelfarce.linux.theplanet.co.uk>,
       Linux Filesystem Development <linux-fsdevel@vger.kernel.org>,
       linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH] private mounts
Message-ID: <20050428082444.GK1906@elf.ucw.cz>
References: <20050426201411.GA20109@elf.ucw.cz> <E1DQiEa-0001hi-00@dorka.pomaz.szeredi.hu> <20050427092450.GB1819@elf.ucw.cz> <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu> <20050427115754.GA8981@vagabond> <E1DQla0-0001vG-00@dorka.pomaz.szeredi.hu> <20050427123944.GA11020@vagabond> <E1DQmUm-0001yy-00@dorka.pomaz.szeredi.hu> <20050427145842.GD28119@elf.ucw.cz> <1114644116.9947.14.camel@lade.trondhjem.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1114644116.9947.14.camel@lade.trondhjem.org>
X-Warning: Reading this can be dangerous to your mental health.
User-Agent: Mutt/1.5.6+20040907i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On St 27-04-05 19:21:56, Trond Myklebust wrote:
> on den 27.04.2005 Klokka 16:58 (+0200) skreiv Pavel Machek:
> 
> > > 
> > > And b) is _the_ most important feature IMO, so the argument for
> > > stripping it out has to be very good.
> > 
> > Well, you'll have problems with suid programs suddenly not being able
> > to access files. nfs gets away with it, but nfs is perceived as
> > "broken" anyway...
> 
> Really?
> 
> The NFS security model is based on the principle that the administrator
> of the SERVER can override access permissions on his/her hardware. Pray
> tell why you think that is "broken"?

Well, administrator on CLIENT can impersonate whoever he wants, and if
data happens to be cached, he can just read them from local memory. So
whatever SERVER administrator does, CLIENT administrator can work
around.
								Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261852AbVD1IkG@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261852AbVD1IkG (ORCPT <rfc822;willy@w.ods.org>);
	Thu, 28 Apr 2005 04:40:06 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261154AbVD1IhI
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 28 Apr 2005 04:37:08 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:18088 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S261862AbVD1I3j (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 28 Apr 2005 04:29:39 -0400
To: pavel@ucw.cz
CC: trond.myklebust@fys.uio.no, bulb@ucw.cz, hch@infradead.org,
       jamie@shareable.org, linuxram@us.ibm.com, 7eggert@gmx.de,
       viro@parcelfarce.linux.theplanet.co.uk, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org, akpm@osdl.org
In-reply-to: <20050428082444.GK1906@elf.ucw.cz> (message from Pavel Machek on
	Thu, 28 Apr 2005 10:24:44 +0200)
Subject: Re: [PATCH] private mounts
References: <20050426201411.GA20109@elf.ucw.cz> <E1DQiEa-0001hi-00@dorka.pomaz.szeredi.hu> <20050427092450.GB1819@elf.ucw.cz> <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu> <20050427115754.GA8981@vagabond> <E1DQla0-0001vG-00@dorka.pomaz.szeredi.hu> <20050427123944.GA11020@vagabond> <E1DQmUm-0001yy-00@dorka.pomaz.szeredi.hu> <20050427145842.GD28119@elf.ucw.cz> <1114644116.9947.14.camel@lade.trondhjem.org> <20050428082444.GK1906@elf.ucw.cz>
Message-Id: <E1DR4OA-0005UL-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Thu, 28 Apr 2005 10:28:50 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> > The NFS security model is based on the principle that the administrator
> > of the SERVER can override access permissions on his/her hardware. Pray
> > tell why you think that is "broken"?
> 
> Well, administrator on CLIENT can impersonate whoever he wants,

Not really.  Root squash has the very important effect that whatever
the client does, it cannot impersonate "root".

Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262072AbVD1LgL@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262072AbVD1LgL (ORCPT <rfc822;willy@w.ods.org>);
	Thu, 28 Apr 2005 07:36:11 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262063AbVD1LgK
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 28 Apr 2005 07:36:10 -0400
Received: from pat.uio.no ([129.240.130.16]:39389 "EHLO pat.uio.no")
	by vger.kernel.org with ESMTP id S262068AbVD1Lfs (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 28 Apr 2005 07:35:48 -0400
Subject: Re: [PATCH] private mounts
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Pavel Machek <pavel@ucw.cz>
Cc: Miklos Szeredi <miklos@szeredi.hu>, bulb@ucw.cz, hch@infradead.org,
       jamie@shareable.org, linuxram@us.ibm.com, 7eggert@gmx.de,
       Alexander Viro <viro@parcelfarce.linux.theplanet.co.uk>,
       Linux Filesystem Development <linux-fsdevel@vger.kernel.org>,
       linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>
In-Reply-To: <20050428082444.GK1906@elf.ucw.cz>
References: <20050426201411.GA20109@elf.ucw.cz>
	 <E1DQiEa-0001hi-00@dorka.pomaz.szeredi.hu>
	 <20050427092450.GB1819@elf.ucw.cz>
	 <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu> <20050427115754.GA8981@vagabond>
	 <E1DQla0-0001vG-00@dorka.pomaz.szeredi.hu>
	 <20050427123944.GA11020@vagabond>
	 <E1DQmUm-0001yy-00@dorka.pomaz.szeredi.hu>
	 <20050427145842.GD28119@elf.ucw.cz>
	 <1114644116.9947.14.camel@lade.trondhjem.org>
	 <20050428082444.GK1906@elf.ucw.cz>
Content-Type: text/plain
Date: Thu, 28 Apr 2005 07:35:17 -0400
Message-Id: <1114688117.10083.7.camel@lade.trondhjem.org>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.639, required 12,
	autolearn=disabled, AWL 1.31, FORGED_RCVD_HELO 0.05,
	UIO_MAIL_IS_INTERNAL -5.00)
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

to den 28.04.2005 Klokka 10:24 (+0200) skreiv Pavel Machek:

> Well, administrator on CLIENT can impersonate whoever he wants, and if
> data happens to be cached, he can just read them from local memory. So
> whatever SERVER administrator does, CLIENT administrator can work
> around.

This is why you have identity squashing and/or strong security: to stop
the CLIENT administrator impersonating whoever he wants and working
around your security measures.

Yes there's all the FUD about how the administrator can still take over
your RPCSEC_GSS creds and/or read cached data once you have logged in.
If you log into a compromised client then you're screwed. What's new?

Trond

-- 
Trond Myklebust <trond.myklebust@fys.uio.no>


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262124AbVD1N2t@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262124AbVD1N2t (ORCPT <rfc822;willy@w.ods.org>);
	Thu, 28 Apr 2005 09:28:49 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262127AbVD1N2t
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 28 Apr 2005 09:28:49 -0400
Received: from wproxy.gmail.com ([64.233.184.195]:23377 "EHLO wproxy.gmail.com")
	by vger.kernel.org with ESMTP id S262124AbVD1N2n convert rfc822-to-8bit
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 28 Apr 2005 09:28:43 -0400
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=d5nPSrQqMXStXzu8YRwztraRw32w+mCkvFA/cqF4TPz4qTvrtOsVB80U15UesgZqbu7tF/TD1/JxzuBgsty7HlnsbPZQ42jhDrZ4H9LcLIgx9vgUqhjhBFQ9HTOktJr+HT2uSElwDOP1eLaavhBmC1gn6PhltzjAGq8b424+qHg=
Message-ID: <a4e6962a050428062821838bcb@mail.gmail.com>
Date: Thu, 28 Apr 2005 08:28:43 -0500
From: Eric Van Hensbergen <ericvh@gmail.com>
Reply-To: Eric Van Hensbergen <ericvh@gmail.com>
To: Jamie Lokier <jamie@shareable.org>
Subject: Re: [PATCH] private mounts
Cc: Pavel Machek <pavel@ucw.cz>,
       Al Viro <viro@parcelfarce.linux.theplanet.co.uk>,
       Miklos Szeredi <miklos@szeredi.hu>, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
In-Reply-To: <20050426140715.GA10833@mail.shareable.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Content-Disposition: inline
References: <E1DPnOn-0000T0-00@localhost> <E1DPo3I-0000V0-00@localhost>
	 <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk>
	 <E1DPoCg-0000W0-00@localhost>
	 <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk>
	 <20050424213822.GB9304@mail.shareable.org>
	 <20050425152049.GB2508@elf.ucw.cz>
	 <20050425190734.GB28294@mail.shareable.org>
	 <20050426092924.GA4175@elf.ucw.cz>
	 <20050426140715.GA10833@mail.shareable.org>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> 
> Looking closer, I think we already have it.
> 
> It's called /proc/NNN/root.
> 
> Does chroot into /proc/NNN/root cause the chroot'ing process to adopt
> the namespace of NNN?  Looking at the code, I think it does.
> 
    ...
> 
> So no new system calls are needed.  A daemon to hand out per-user
> namespaces (or any other policy) can be written using existing
> kernels, and those namespaces can be joined using chroot.
> 
> That's the theory anyway.  It's always possible I misread the code (as
> I don't use namespaces and don't have tools handy to try them).
> 

I've been thinking about this a bit more...would you even need chroot?
(wouldn't exposing chroot functionality to a user incur additional
security risk?  I guess it would be okay as long as you were only
chrooting to one of your other process' roots?)

If you were organized about where the mounts in your private namespace
were done, you could just mount -bind them from
/proc/NNN/root/home/$USER/mnt (or something).  That requries a certain
amount of discipline in your mounts (or maybe not -- just diff
/proc/NNN/mounts to see what you are missing and bind the
differences).

         -eric

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262132AbVD1Nrs@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262132AbVD1Nrs (ORCPT <rfc822;willy@w.ods.org>);
	Thu, 28 Apr 2005 09:47:48 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262138AbVD1Nrs
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 28 Apr 2005 09:47:48 -0400
Received: from wproxy.gmail.com ([64.233.184.195]:57174 "EHLO wproxy.gmail.com")
	by vger.kernel.org with ESMTP id S262133AbVD1Nrp convert rfc822-to-8bit
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 28 Apr 2005 09:47:45 -0400
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=fFeRxdi29RnfRGhjbEzwOh3uUTVhqn4swoSp8rLBb1LiP7NSJK6iDEY4AB8em7AdXrIe6W/7YQdq7fKaqf5d1Rum0a3HudHUWNELCTSnVKKqZ4XdOWeIQLWiGFbJhXyQSQP11BfiRH4ZP+3erYw29j63PYA+uzCQy/i8vpT3xw8=
Message-ID: <a4e6962a050428064774e88f4a@mail.gmail.com>
Date: Thu, 28 Apr 2005 08:47:44 -0500
From: Eric Van Hensbergen <ericvh@gmail.com>
Reply-To: Eric Van Hensbergen <ericvh@gmail.com>
To: Jamie Lokier <jamie@shareable.org>
Subject: Re: [PATCH] private mounts
Cc: Pavel Machek <pavel@ucw.cz>,
       Al Viro <viro@parcelfarce.linux.theplanet.co.uk>,
       Miklos Szeredi <miklos@szeredi.hu>, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
In-Reply-To: <20050426140715.GA10833@mail.shareable.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Content-Disposition: inline
References: <E1DPnOn-0000T0-00@localhost> <E1DPo3I-0000V0-00@localhost>
	 <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk>
	 <E1DPoCg-0000W0-00@localhost>
	 <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk>
	 <20050424213822.GB9304@mail.shareable.org>
	 <20050425152049.GB2508@elf.ucw.cz>
	 <20050425190734.GB28294@mail.shareable.org>
	 <20050426092924.GA4175@elf.ucw.cz>
	 <20050426140715.GA10833@mail.shareable.org>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On 4/26/05, Jamie Lokier <jamie@shareable.org> wrote:
> 
> It's called /proc/NNN/root.
> 
> So no new system calls are needed.  A daemon to hand out per-user
> namespaces (or any other policy) can be written using existing
> kernels, and those namespaces can be joined using chroot.
> 
> That's the theory anyway.  It's always possible I misread the code (as
> I don't use namespaces and don't have tools handy to try them).
> 

Should have checked myself before posting my previous reply -- but
this doesn't seem to work.  /proc/NNN/root is represented as a
symlink, but when you CLONE_NS and then try to look at another one of
your process' /proc/NNN/root the link doesn't seem to have a target
and you get permission denied on all accesses.  I haven't looked at
the underlying procfs code, but adapting procfs for this sort of
purpose feels wrong.

          -eric

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262197AbVD1R7E@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262197AbVD1R7E (ORCPT <rfc822;willy@w.ods.org>);
	Thu, 28 Apr 2005 13:59:04 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262201AbVD1R7E
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 28 Apr 2005 13:59:04 -0400
Received: from e5.ny.us.ibm.com ([32.97.182.145]:37092 "EHLO e5.ny.us.ibm.com")
	by vger.kernel.org with ESMTP id S262197AbVD1R66 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 28 Apr 2005 13:58:58 -0400
In-Reply-To: <1114688117.10083.7.camel@lade.trondhjem.org>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: 7eggert@gmx.de, Andrew Morton <akpm@osdl.org>, bulb@ucw.cz,
       hch@infradead.org, jamie@shareable.org,
       Linux Filesystem Development <linux-fsdevel@vger.kernel.org>,
       linux-kernel@vger.kernel.org, linuxram@us.ibm.com,
       Miklos Szeredi <miklos@szeredi.hu>, Pavel Machek <pavel@ucw.cz>,
       Alexander Viro <viro@parcelfarce.linux.theplanet.co.uk>
MIME-Version: 1.0
Subject: Re: [PATCH] private mounts
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OFF95431C8.830FB697-ON88256FF1.006112B7-88256FF1.0062D7C3@us.ibm.com>
From: Bryan Henderson <hbryan@us.ibm.com>
Date: Thu, 28 Apr 2005 10:58:18 -0700
X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Build V70_M4_01112005 Beta 3|January
 11, 2005) at 04/28/2005 13:58:55,
	Serialize complete at 04/28/2005 13:58:55
Content-Type: text/plain; charset="US-ASCII"
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

>This is why you have identity squashing and/or strong security: to stop
>the CLIENT administrator impersonating whoever he wants and working
>around your security measures.

That's more of a confirmation than a refutation of the statement that NFS 
root squashing is broken.  Root squashing itself simply does not squash a 
typical system administrator's ability to get at other people's files. 
"broken" isn't the right word, because as long as you recognize root 
squashing for what it is, it's working as designed.  It just isn't what it 
appears to be.

But, in the context of the current thread, I think the perception of NFS 
root squashing as something broken and not to be built upon with private 
mounts has to do with the fact that it messes up Linux's basic file 
permission scheme:  a process with CAP_DAC_OVERRIDE can get EACCES. 
EACCESS means discretionary access controls (DAC) prevent access.  So this 
behavior is unexpected and unnatural.  Worse, an operation can succeed 
_without_ CAP_DAC_OVERRIDE, but not _with_ it.  I've seen this behavior 
cause trouble a number of times -- mostly because it's entirely 
unanticipated.

--
Bryan Henderson                          IBM Almaden Research Center
San Jose CA                              Filesystems

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262213AbVD1SOo@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262213AbVD1SOo (ORCPT <rfc822;willy@w.ods.org>);
	Thu, 28 Apr 2005 14:14:44 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262205AbVD1SOa
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 28 Apr 2005 14:14:30 -0400
Received: from atrey.karlin.mff.cuni.cz ([195.113.31.123]:53689 "EHLO
	atrey.karlin.mff.cuni.cz") by vger.kernel.org with ESMTP
	id S262207AbVD1SLu (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 28 Apr 2005 14:11:50 -0400
Date: Thu, 28 Apr 2005 15:08:19 +0200
From: Pavel Machek <pavel@suse.cz>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: mj@ucw.cz, lmb@suse.de, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050428130819.GF2226@openzaurus.ucw.cz>
References: <20050427092450.GB1819@elf.ucw.cz> <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu> <20050427143126.GB1957@mail.shareable.org> <E1DQno0-00029a-00@dorka.pomaz.szeredi.hu> <20050427153320.GA19065@atrey.karlin.mff.cuni.cz> <20050427155022.GR4431@marowsky-bree.de> <20050427164652.GA3129@ucw.cz> <E1DQqUi-0002Pt-00@dorka.pomaz.szeredi.hu> <20050427175425.GA4241@ucw.cz> <E1DQquc-0002W6-00@dorka.pomaz.szeredi.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1DQquc-0002W6-00@dorka.pomaz.szeredi.hu>
User-Agent: Mutt/1.3.27i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Hi!

> > > Is it possible to limit all these from kernelspace?  Probably yes,
> > > although a timeout for operations is something that cuts either way.
> > > And the compexity of these checks would probably be orders of
> > > magnitude higher then the check we are currently discussing.
> > 
> > Yes ... but does the check we are discussing really solve the
> > problem?
> > 
> > Let's say that you attempt to export home directories of users by a
> > user-space NFS daemon. This daemon probably changes its fsuid to
> > match the remote user, so the check happily accepts the access and
> > the user is able to lock up the daemon.
> 
> Valid point.  The only defense is that when a program set's fsuid,
> it's performing the operation "on behalf of the user".  So the user is
> actually doing DoS against himself.
> 
> Of course this is not strictly true.  E.g. in the userspace NFS case
> it's probably a DoS against all users of the mount.

Exactly. So can we simply merge root-only fuse, and then worry
how to make it safe with user-mounted fuse. See your own unfsd example
why user-mounting is bad.

One possible solution would be to have root-owned fused that
talks to user-owned fused-s and checks they are behaving correctly?

Second is somehow improving those two lines this long thread is all about...

				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262240AbVD1TVS@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262240AbVD1TVS (ORCPT <rfc822;willy@w.ods.org>);
	Thu, 28 Apr 2005 15:21:18 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262239AbVD1TVR
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 28 Apr 2005 15:21:17 -0400
Received: from mail.shareable.org ([81.29.64.88]:39850 "EHLO
	mail.shareable.org") by vger.kernel.org with ESMTP id S262220AbVD1TVJ
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 28 Apr 2005 15:21:09 -0400
Date: Thu, 28 Apr 2005 20:20:48 +0100
From: Jamie Lokier <jamie@shareable.org>
To: Eric Van Hensbergen <ericvh@gmail.com>
Cc: Pavel Machek <pavel@ucw.cz>,
       Al Viro <viro@parcelfarce.linux.theplanet.co.uk>,
       Miklos Szeredi <miklos@szeredi.hu>, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050428192048.GA2895@mail.shareable.org>
References: <E1DPo3I-0000V0-00@localhost> <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk> <E1DPoCg-0000W0-00@localhost> <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk> <20050424213822.GB9304@mail.shareable.org> <20050425152049.GB2508@elf.ucw.cz> <20050425190734.GB28294@mail.shareable.org> <20050426092924.GA4175@elf.ucw.cz> <20050426140715.GA10833@mail.shareable.org> <a4e6962a050428064774e88f4a@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <a4e6962a050428064774e88f4a@mail.gmail.com>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Eric Van Hensbergen wrote:
> > It's called /proc/NNN/root.
> > 
> > So no new system calls are needed.  A daemon to hand out per-user
> > namespaces (or any other policy) can be written using existing
> > kernels, and those namespaces can be joined using chroot.
> > 
> > That's the theory anyway.  It's always possible I misread the code (as
> > I don't use namespaces and don't have tools handy to try them).
> > 
> 
> Should have checked myself before posting my previous reply -- but
> this doesn't seem to work.  /proc/NNN/root is represented as a
> symlink, but when you CLONE_NS and then try to look at another one of
> your process' /proc/NNN/root the link doesn't seem to have a target
> and you get permission denied on all accesses.

I've looked at the code.  Look in fs/proc/base.c (Linux 2.6.10),
proc_root_link().

I don't see anything there to prevent you from traversing to the
mounts in the other namespace.

So why is it failing?  Any idea?

> I haven't looked at the underlying procfs code, but adapting procfs
> for this sort of purpose feels wrong.

Having a file/directory which represents namespaces held by another
process makes much more sense to me than new system calls and
inventing yet another id space to represent namespaces.

And, given that you can look at the filesystems another process can
see by doing ptrace on it, it might as well be accessible in a more
natural way.

-- Jamie

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262241AbVD1TX0@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262241AbVD1TX0 (ORCPT <rfc822;willy@w.ods.org>);
	Thu, 28 Apr 2005 15:23:26 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262243AbVD1TXN
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 28 Apr 2005 15:23:13 -0400
Received: from mail.shareable.org ([81.29.64.88]:42154 "EHLO
	mail.shareable.org") by vger.kernel.org with ESMTP id S262241AbVD1TWf
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 28 Apr 2005 15:22:35 -0400
Date: Thu, 28 Apr 2005 20:22:23 +0100
From: Jamie Lokier <jamie@shareable.org>
To: Eric Van Hensbergen <ericvh@gmail.com>
Cc: Pavel Machek <pavel@ucw.cz>,
       Al Viro <viro@parcelfarce.linux.theplanet.co.uk>,
       Miklos Szeredi <miklos@szeredi.hu>, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050428192223.GB2895@mail.shareable.org>
References: <E1DPo3I-0000V0-00@localhost> <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk> <E1DPoCg-0000W0-00@localhost> <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk> <20050424213822.GB9304@mail.shareable.org> <20050425152049.GB2508@elf.ucw.cz> <20050425190734.GB28294@mail.shareable.org> <20050426092924.GA4175@elf.ucw.cz> <20050426140715.GA10833@mail.shareable.org> <a4e6962a050428062821838bcb@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <a4e6962a050428062821838bcb@mail.gmail.com>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Eric Van Hensbergen wrote:
> > Does chroot into /proc/NNN/root cause the chroot'ing process to adopt
> > the namespace of NNN?  Looking at the code, I think it does.
> 
> I've been thinking about this a bit more...would you even need chroot?
> (wouldn't exposing chroot functionality to a user incur additional
> security risk?  I guess it would be okay as long as you were only
> chrooting to one of your other process' roots?)

You don't need to let an ordinary user do chroot.

The login process can do it before it changes uid to the user, the
same as it does to set up all the other per-user parameters.

-- Jamie

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262214AbVD1Tak@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262214AbVD1Tak (ORCPT <rfc822;willy@w.ods.org>);
	Thu, 28 Apr 2005 15:30:40 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262251AbVD1Taj
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 28 Apr 2005 15:30:39 -0400
Received: from e31.co.us.ibm.com ([32.97.110.129]:46020 "EHLO
	e31.co.us.ibm.com") by vger.kernel.org with ESMTP id S262245AbVD1TaG
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 28 Apr 2005 15:30:06 -0400
Subject: Re: [PATCH] private mounts
From: Ram <linuxram@us.ibm.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: lmb@suse.de, mj@ucw.cz, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org
In-Reply-To: <E1DR312-0005IZ-00@dorka.pomaz.szeredi.hu>
References: <20050426094727.GA30379@infradead.org>
	 <20050426131943.GC2226@openzaurus.ucw.cz>
	 <E1DQQ73-0000Zv-00@dorka.pomaz.szeredi.hu>
	 <20050426201411.GA20109@elf.ucw.cz>
	 <E1DQiEa-0001hi-00@dorka.pomaz.szeredi.hu>
	 <20050427092450.GB1819@elf.ucw.cz>
	 <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu>
	 <20050427143126.GB1957@mail.shareable.org>
	 <E1DQno0-00029a-00@dorka.pomaz.szeredi.hu>
	 <20050427153320.GA19065@atrey.karlin.mff.cuni.cz>
	 <20050427155022.GR4431@marowsky-bree.de>
	 <E1DQqQ0-0002PB-00@dorka.pomaz.szeredi.hu>
	 <1114623598.4480.181.camel@localhost>
	 <E1DQqdW-0002SN-00@dorka.pomaz.szeredi.hu>
	 <1114624541.4480.187.camel@localhost>
	 <E1DQqyY-0002WW-00@dorka.pomaz.szeredi.hu>
	 <1114630811.4180.20.camel@localhost>
	 <E1DQskk-0004dI-00@dorka.pomaz.szeredi.hu>
	 <1114637883.4180.55.camel@localhost>
	 <E1DR312-0005IZ-00@dorka.pomaz.szeredi.hu>
Content-Type: text/plain
Organization: IBM 
Message-Id: <1114716602.4180.701.camel@localhost>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 
Date: Thu, 28 Apr 2005 12:30:02 -0700
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, 2005-04-28 at 00:00, Miklos Szeredi wrote:
> > ok. Generally overmounts are done on the root dentry of the topmost
> > vfsmount.  But in this case, your patch mounts it on the same dentry
> > as that of the private mount.
> > 
> > Essentially I was always under the assertion that 'a dentry can hold
> > only one vfsmount'.  But invisible mount seem to invalidate that
> > assertion.
> 
> You can do that without an invisible mount:
> 
> mkdir /tmp/mnt
> mkdir /tmp/dir1
> mkdir /tmp/dir1/subdir1
> mkdir /tmp/dir2
> mkdir /tmp/dir2/subdir2
> 
> cd /tmp/mnt
> mount --bind /tmp/dir1 .
> mount --bind /tmp/dir2 .
> 
> Now you have both /tmp/dir1 and /tmp/dir2 rooted at the same dentry.

Ok. got it!. Agreed. great example!

Thanks,
RP


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262251AbVD1Tj7@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262251AbVD1Tj7 (ORCPT <rfc822;willy@w.ods.org>);
	Thu, 28 Apr 2005 15:39:59 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262238AbVD1Tj7
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 28 Apr 2005 15:39:59 -0400
Received: from e5.ny.us.ibm.com ([32.97.182.145]:8104 "EHLO e5.ny.us.ibm.com")
	by vger.kernel.org with ESMTP id S262252AbVD1Tjs (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 28 Apr 2005 15:39:48 -0400
Subject: Re: [PATCH] private mounts
From: Ram <linuxram@us.ibm.com>
To: Jamie Lokier <jamie@shareable.org>
Cc: Eric Van Hensbergen <ericvh@gmail.com>, Pavel Machek <pavel@ucw.cz>,
       Al Viro <viro@parcelfarce.linux.theplanet.co.uk>,
       Miklos Szeredi <miklos@szeredi.hu>, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       Andrew Morton <akpm@osdl.org>
In-Reply-To: <20050428192048.GA2895@mail.shareable.org>
References: <E1DPo3I-0000V0-00@localhost>
	 <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk>
	 <E1DPoCg-0000W0-00@localhost>
	 <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk>
	 <20050424213822.GB9304@mail.shareable.org>
	 <20050425152049.GB2508@elf.ucw.cz>
	 <20050425190734.GB28294@mail.shareable.org>
	 <20050426092924.GA4175@elf.ucw.cz>
	 <20050426140715.GA10833@mail.shareable.org>
	 <a4e6962a050428064774e88f4a@mail.gmail.com>
	 <20050428192048.GA2895@mail.shareable.org>
Content-Type: text/plain
Organization: IBM 
Message-Id: <1114717183.4180.718.camel@localhost>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 
Date: Thu, 28 Apr 2005 12:39:44 -0700
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, 2005-04-28 at 12:20, Jamie Lokier wrote:
> Eric Van Hensbergen wrote:
> > > It's called /proc/NNN/root.
> > > 
> > > So no new system calls are needed.  A daemon to hand out per-user
> > > namespaces (or any other policy) can be written using existing
> > > kernels, and those namespaces can be joined using chroot.
> > > 
> > > That's the theory anyway.  It's always possible I misread the code (as
> > > I don't use namespaces and don't have tools handy to try them).
> > > 
> > 
> > Should have checked myself before posting my previous reply -- but
> > this doesn't seem to work.  /proc/NNN/root is represented as a
> > symlink, but when you CLONE_NS and then try to look at another one of
> > your process' /proc/NNN/root the link doesn't seem to have a target
> > and you get permission denied on all accesses.
> 
> I've looked at the code.  Look in fs/proc/base.c (Linux 2.6.10),
> proc_root_link().
> 
> I don't see anything there to prevent you from traversing to the
> mounts in the other namespace.
> 
> So why is it failing?  Any idea?

Since you are traversing a symlink, you will be traversing the symlink
in the context of traversing process's namespace. 

If process 'x' is traversing /proc/y/root , the lookup for the root
dentry will happen in the context of process x's  namespace, and not
process y's namespace. Hence process 'x' wont really get into
the namespace of the process y.

RP


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262253AbVD1TmT@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262253AbVD1TmT (ORCPT <rfc822;willy@w.ods.org>);
	Thu, 28 Apr 2005 15:42:19 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262252AbVD1TmT
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 28 Apr 2005 15:42:19 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:65449 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S262248AbVD1TmJ (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 28 Apr 2005 15:42:09 -0400
To: pavel@suse.cz
CC: mj@ucw.cz, lmb@suse.de, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org
In-reply-to: <20050428130819.GF2226@openzaurus.ucw.cz> (message from Pavel
	Machek on Thu, 28 Apr 2005 15:08:19 +0200)
Subject: Re: [PATCH] private mounts
References: <20050427092450.GB1819@elf.ucw.cz> <E1DQjzY-0001no-00@dorka.pomaz.szeredi.hu> <20050427143126.GB1957@mail.shareable.org> <E1DQno0-00029a-00@dorka.pomaz.szeredi.hu> <20050427153320.GA19065@atrey.karlin.mff.cuni.cz> <20050427155022.GR4431@marowsky-bree.de> <20050427164652.GA3129@ucw.cz> <E1DQqUi-0002Pt-00@dorka.pomaz.szeredi.hu> <20050427175425.GA4241@ucw.cz> <E1DQquc-0002W6-00@dorka.pomaz.szeredi.hu> <20050428130819.GF2226@openzaurus.ucw.cz>
Message-Id: <E1DREtK-0006Ha-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Thu, 28 Apr 2005 21:41:42 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> Exactly. So can we simply merge root-only fuse, and then worry
> how to make it safe with user-mounted fuse. See your own unfsd example
> why user-mounting is bad.
> 
> One possible solution would be to have root-owned fused that
> talks to user-owned fused-s and checks they are behaving correctly?

It's very hard to do that.  What should be the timeout for requests,
so that valid filesystems don't break, yet it's not possible to do a
fairly ugly DoS?  It's almost impossible I'd say.

> Second is somehow improving those two lines this long thread is all about...

That's what I did.  See the recent documentation and code patches
(cc-d to -fsdevel).  I'm pretty convinced it's the right thing to do.
OK, I was with the previous solution too, but anyway ;)

Thanks,
Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262252AbVD1Tqj@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262252AbVD1Tqj (ORCPT <rfc822;willy@w.ods.org>);
	Thu, 28 Apr 2005 15:46:39 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262244AbVD1Tqj
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 28 Apr 2005 15:46:39 -0400
Received: from pat.uio.no ([129.240.130.16]:41412 "EHLO pat.uio.no")
	by vger.kernel.org with ESMTP id S262220AbVD1Tq1 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 28 Apr 2005 15:46:27 -0400
Subject: Re: [PATCH] private mounts
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Bryan Henderson <hbryan@us.ibm.com>
Cc: 7eggert@gmx.de, Andrew Morton <akpm@osdl.org>, bulb@ucw.cz,
       hch@infradead.org, jamie@shareable.org,
       Linux Filesystem Development <linux-fsdevel@vger.kernel.org>,
       linux-kernel@vger.kernel.org, linuxram@us.ibm.com,
       Miklos Szeredi <miklos@szeredi.hu>, Pavel Machek <pavel@ucw.cz>,
       Alexander Viro <viro@parcelfarce.linux.theplanet.co.uk>
In-Reply-To: <OFF95431C8.830FB697-ON88256FF1.006112B7-88256FF1.0062D7C3@us.ibm.com>
References: <OFF95431C8.830FB697-ON88256FF1.006112B7-88256FF1.0062D7C3@us.ibm.com>
Content-Type: text/plain
Date: Thu, 28 Apr 2005 15:46:07 -0400
Message-Id: <1114717567.11547.82.camel@lade.trondhjem.org>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.857, required 12,
	autolearn=disabled, AWL 1.14, UIO_MAIL_IS_INTERNAL -5.00)
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

to den 28.04.2005 Klokka 10:58 (-0700) skreiv Bryan Henderson:
> >This is why you have identity squashing and/or strong security: to stop
> >the CLIENT administrator impersonating whoever he wants and working
> >around your security measures.
> 
> That's more of a confirmation than a refutation of the statement that NFS 
> root squashing is broken.  Root squashing itself simply does not squash a 
> typical system administrator's ability to get at other people's files. 
> "broken" isn't the right word, because as long as you recognize root 
> squashing for what it is, it's working as designed.  It just isn't what it 
> appears to be.

Root squashing is there to enforce the policy that nobody gets to access
any files with uid=0,gid=0. IOW it is a policy that is first and
foremost meant to make root-owned files untouchable.

Strong security, OTOH, enforces the policy that you need to authenticate
as a given person in order to get at that person's files.

Neither can prevent man-in-the-middle style attacks by root on a client
that is compromised nor can they stop someone who has managed to lift
your username+password from somewhere. Every security policy has its
limitations.

> But, in the context of the current thread, I think the perception of NFS 
> root squashing as something broken and not to be built upon with private 
> mounts has to do with the fact that it messes up Linux's basic file 
> permission scheme:  a process with CAP_DAC_OVERRIDE can get EACCES. 
> EACCESS means discretionary access controls (DAC) prevent access.  So this 
> behavior is unexpected and unnatural.  Worse, an operation can succeed 
> _without_ CAP_DAC_OVERRIDE, but not _with_ it.  I've seen this behavior 
> cause trouble a number of times -- mostly because it's entirely 
> unanticipated.

Tough. Your administrator has set a certain policy on the fileserver,
and it is being correctly enforced. If that policy decision turns out to
be unnecessarily strict then you are quite free to plead with the
administrator to change it.

Note that these days CAP_DAC_OVERRIDE is no longer guaranteed to be
sufficient even for local disk if the administrator is using LSE to set
up custom policies.

Cheers,
  Trond
-- 
Trond Myklebust <trond.myklebust@fys.uio.no>


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262138AbVD1UVv@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262138AbVD1UVv (ORCPT <rfc822;willy@w.ods.org>);
	Thu, 28 Apr 2005 16:21:51 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262127AbVD1UVv
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 28 Apr 2005 16:21:51 -0400
Received: from gprs189-60.eurotel.cz ([160.218.189.60]:23515 "EHLO amd.ucw.cz")
	by vger.kernel.org with ESMTP id S262111AbVD1UVq (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 28 Apr 2005 16:21:46 -0400
Date: Thu, 28 Apr 2005 22:21:27 +0200
From: Pavel Machek <pavel@suse.cz>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: mj@ucw.cz, lmb@suse.de, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050428202127.GC12431@elf.ucw.cz>
References: <20050427143126.GB1957@mail.shareable.org> <E1DQno0-00029a-00@dorka.pomaz.szeredi.hu> <20050427153320.GA19065@atrey.karlin.mff.cuni.cz> <20050427155022.GR4431@marowsky-bree.de> <20050427164652.GA3129@ucw.cz> <E1DQqUi-0002Pt-00@dorka.pomaz.szeredi.hu> <20050427175425.GA4241@ucw.cz> <E1DQquc-0002W6-00@dorka.pomaz.szeredi.hu> <20050428130819.GF2226@openzaurus.ucw.cz> <E1DREtK-0006Ha-00@dorka.pomaz.szeredi.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1DREtK-0006Ha-00@dorka.pomaz.szeredi.hu>
X-Warning: Reading this can be dangerous to your mental health.
User-Agent: Mutt/1.5.6+20040907i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Hi!

> > Exactly. So can we simply merge root-only fuse, and then worry
> > how to make it safe with user-mounted fuse. See your own unfsd example
> > why user-mounting is bad.
> > 
> > One possible solution would be to have root-owned fused that
> > talks to user-owned fused-s and checks they are behaving correctly?
> 
> It's very hard to do that.  What should be the timeout for requests,
> so that valid filesystems don't break, yet it's not possible to do a
> fairly ugly DoS?  It's almost impossible I'd say.

You can still put those two lines into root-owned fused, where people
are less likely to notice them ;-).
								Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262287AbVD1WJT@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262287AbVD1WJT (ORCPT <rfc822;willy@w.ods.org>);
	Thu, 28 Apr 2005 18:09:19 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262286AbVD1WJT
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 28 Apr 2005 18:09:19 -0400
Received: from mail.shareable.org ([81.29.64.88]:48298 "EHLO
	mail.shareable.org") by vger.kernel.org with ESMTP id S262285AbVD1WJJ
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 28 Apr 2005 18:09:09 -0400
Date: Thu, 28 Apr 2005 23:08:39 +0100
From: Jamie Lokier <jamie@shareable.org>
To: Ram <linuxram@us.ibm.com>
Cc: Eric Van Hensbergen <ericvh@gmail.com>, Pavel Machek <pavel@ucw.cz>,
       Al Viro <viro@parcelfarce.linux.theplanet.co.uk>,
       Miklos Szeredi <miklos@szeredi.hu>, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH] private mounts
Message-ID: <20050428220839.GA5183@mail.shareable.org>
References: <E1DPoCg-0000W0-00@localhost> <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk> <20050424213822.GB9304@mail.shareable.org> <20050425152049.GB2508@elf.ucw.cz> <20050425190734.GB28294@mail.shareable.org> <20050426092924.GA4175@elf.ucw.cz> <20050426140715.GA10833@mail.shareable.org> <a4e6962a050428064774e88f4a@mail.gmail.com> <20050428192048.GA2895@mail.shareable.org> <1114717183.4180.718.camel@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1114717183.4180.718.camel@localhost>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Ram wrote:
> > I've looked at the code.  Look in fs/proc/base.c (Linux 2.6.10),
> > proc_root_link().
> > 
> > I don't see anything there to prevent you from traversing to the
> > mounts in the other namespace.
> > 
> > So why is it failing?  Any idea?
> 
> Since you are traversing a symlink, you will be traversing the symlink
> in the context of traversing process's namespace. 
> 
> If process 'x' is traversing /proc/y/root , the lookup for the root
> dentry will happen in the context of process x's  namespace, and not
> process y's namespace. Hence process 'x' wont really get into
> the namespace of the process y.

Lookups don't happen in the context of a namespace.

They happen in the context of a vfsmnt.  And the switch to a new
vfsmnt is done by matching against (dentry,parent-vfsmnt) pairs.
current->namespace is only checked for mount & unmount operations, not
for path lookups.

Which means proc_root_link, when it switches to the vfsmnt at the root
of the other process, should traverse into the tree of vfsmnts which
make up the other namespace.

-- Jamie

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262312AbVD1WkW@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262312AbVD1WkW (ORCPT <rfc822;willy@w.ods.org>);
	Thu, 28 Apr 2005 18:40:22 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262316AbVD1WkU
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 28 Apr 2005 18:40:20 -0400
Received: from e3.ny.us.ibm.com ([32.97.182.143]:50138 "EHLO e3.ny.us.ibm.com")
	by vger.kernel.org with ESMTP id S262312AbVD1Wj0 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 28 Apr 2005 18:39:26 -0400
In-Reply-To: <1114717567.11547.82.camel@lade.trondhjem.org>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: 7eggert@gmx.de, Andrew Morton <akpm@osdl.org>, bulb@ucw.cz,
       hch@infradead.org, jamie@shareable.org,
       Linux Filesystem Development <linux-fsdevel@vger.kernel.org>,
       linux-kernel@vger.kernel.org, linuxram@us.ibm.com,
       Miklos Szeredi <miklos@szeredi.hu>, Pavel Machek <pavel@ucw.cz>,
       Alexander Viro <viro@parcelfarce.linux.theplanet.co.uk>
MIME-Version: 1.0
Subject: Re: [PATCH] private mounts
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <OFAECB8B29.CBF40C89-ON88256FF1.00790823-88256FF1.007C85B5@us.ibm.com>
From: Bryan Henderson <hbryan@us.ibm.com>
Date: Thu, 28 Apr 2005 15:38:48 -0700
X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Build V70_M4_01112005 Beta 3|January
 11, 2005) at 04/28/2005 18:39:23,
	Serialize complete at 04/28/2005 18:39:23,
	Serialize by Router on D01ML604/01/M/IBM(Build V70_M4_01112005 Beta 3|January
 11, 2005) at 04/28/2005 18:39:24
Content-Type: text/plain; charset="US-ASCII"
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

>Root squashing is there to enforce the policy that nobody gets to access
>any files with uid=0,gid=0. IOW it is a policy that is first and
>foremost meant to make root-owned files untouchable.

That's the only thing it does well, but you'd have to convince me that 
that's what it was designed for and that's what everyone expects out of 
it.  The most salient effect of root squashing -- the one that takes 
people by surprise -- is that it removes the special rights an NFS server 
otherwise accords to uid 0.  If protecting files owned by uid=0, gid=0 
were the original design goal, the protocol could have been designed to do 
that while still giving uid 0 access to everybody else's files.

>>a process with CAP_DAC_OVERRIDE can get EACCES.  ... Whine, whine...
>Tough.

This is actually off-topic.  We're not talking about whether root 
squashing is a good compromise.  We started with the statement that the 
only existing thing like (some private mount proposal) is NFS root 
squashing and the statement that some people consider that broken.  That 
elicited a response from you that suggested you were unaware there was 
anything not to like about root squashing ("Really?") and then some 
descriptions of the objections.  The fact is that negative perceptions of 
root squashing exist.  I know you know that.  There are respectable 
technical people who don't agree with the compromise.  So if one is 
looking for a broadly acceptable design of private mounts, one might want 
to find one that doesn't use NFS root squashing as its precedent.

--
Bryan Henderson                          IBM Almaden Research Center
San Jose CA                              Filesystems


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262361AbVD2Ag3@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262361AbVD2Ag3 (ORCPT <rfc822;willy@w.ods.org>);
	Thu, 28 Apr 2005 20:36:29 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262359AbVD2Ag3
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Thu, 28 Apr 2005 20:36:29 -0400
Received: from pat.uio.no ([129.240.130.16]:63119 "EHLO pat.uio.no")
	by vger.kernel.org with ESMTP id S262358AbVD2AgN (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 28 Apr 2005 20:36:13 -0400
Subject: Re: [PATCH] private mounts
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Bryan Henderson <hbryan@us.ibm.com>
Cc: 7eggert@gmx.de, Andrew Morton <akpm@osdl.org>, bulb@ucw.cz,
       hch@infradead.org, jamie@shareable.org,
       Linux Filesystem Development <linux-fsdevel@vger.kernel.org>,
       linux-kernel@vger.kernel.org, linuxram@us.ibm.com,
       Miklos Szeredi <miklos@szeredi.hu>, Pavel Machek <pavel@ucw.cz>,
       Alexander Viro <viro@parcelfarce.linux.theplanet.co.uk>
In-Reply-To: <OFAECB8B29.CBF40C89-ON88256FF1.00790823-88256FF1.007C85B5@us.ibm.com>
References: <OFAECB8B29.CBF40C89-ON88256FF1.00790823-88256FF1.007C85B5@us.ibm.com>
Content-Type: text/plain
Date: Thu, 28 Apr 2005 20:35:51 -0400
Message-Id: <1114734951.9738.30.camel@lade.trondhjem.org>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 
Content-Transfer-Encoding: 7bit
X-UiO-Spam-info: not spam, SpamAssassin (score=-3.518, required 12,
	autolearn=disabled, AWL 1.48, UIO_MAIL_IS_INTERNAL -5.00)
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

to den 28.04.2005 Klokka 15:38 (-0700) skreiv Bryan Henderson:
> >Root squashing is there to enforce the policy that nobody gets to access
> >any files with uid=0,gid=0. IOW it is a policy that is first and
> >foremost meant to make root-owned files untouchable.
> 
> That's the only thing it does well, but you'd have to convince me that 
> that's what it was designed for and that's what everyone expects out of 
> it.  The most salient effect of root squashing -- the one that takes 
> people by surprise -- is that it removes the special rights an NFS server 
> otherwise accords to uid 0.  If protecting files owned by uid=0, gid=0 
> were the original design goal, the protocol could have been designed to do 
> that while still giving uid 0 access to everybody else's files.

That is much harder to do. The nfs server would have to take over the
permissions checking on behalf of whatever it is exporting for all
operations.

> >>a process with CAP_DAC_OVERRIDE can get EACCES.  ... Whine, whine...
> >Tough.
> 
> This is actually off-topic.  We're not talking about whether root 
> squashing is a good compromise.  We started with the statement that the 
> only existing thing like (some private mount proposal) is NFS root 
> squashing and the statement that some people consider that broken.  That 
> elicited a response from you that suggested you were unaware there was 
> anything not to like about root squashing ("Really?") and then some 
> descriptions of the objections.  The fact is that negative perceptions of 
> root squashing exist.  I know you know that.  There are respectable 
> technical people who don't agree with the compromise.  So if one is 
> looking for a broadly acceptable design of private mounts, one might want 
> to find one that doesn't use NFS root squashing as its precedent.

The lack of agreement on root squashing is a reason for it to be a
matter of administrator-defined policy, and why the solution chosen
_should_ allow for that kind of behaviour.

If the user is free to futz around with the namespace, then it makes a
lot of sense for administrators to want to restrict access to this
user-defined namespace to non-suid programs that won't start screwing
round with opening files on arbitrary filesystems using the wrong
credentials and/or capabilities.
Particularly so if the user is capable of mounting remote filesystems.

Trond
-- 
Trond Myklebust <trond.myklebust@fys.uio.no>


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262458AbVD2H5Z@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262458AbVD2H5Z (ORCPT <rfc822;willy@w.ods.org>);
	Fri, 29 Apr 2005 03:57:25 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262456AbVD2H5Z
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Fri, 29 Apr 2005 03:57:25 -0400
Received: from e6.ny.us.ibm.com ([32.97.182.146]:50644 "EHLO e6.ny.us.ibm.com")
	by vger.kernel.org with ESMTP id S262454AbVD2H5P (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 29 Apr 2005 03:57:15 -0400
Subject: Re: [PATCH] private mounts
From: Ram <linuxram@us.ibm.com>
To: Jamie Lokier <jamie@shareable.org>
Cc: Eric Van Hensbergen <ericvh@gmail.com>, Pavel Machek <pavel@ucw.cz>,
       Al Viro <viro@parcelfarce.linux.theplanet.co.uk>,
       Miklos Szeredi <miklos@szeredi.hu>, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       Andrew Morton <akpm@osdl.org>
In-Reply-To: <20050428220839.GA5183@mail.shareable.org>
References: <E1DPoCg-0000W0-00@localhost>
	 <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk>
	 <20050424213822.GB9304@mail.shareable.org>
	 <20050425152049.GB2508@elf.ucw.cz>
	 <20050425190734.GB28294@mail.shareable.org>
	 <20050426092924.GA4175@elf.ucw.cz>
	 <20050426140715.GA10833@mail.shareable.org>
	 <a4e6962a050428064774e88f4a@mail.gmail.com>
	 <20050428192048.GA2895@mail.shareable.org>
	 <1114717183.4180.718.camel@localhost>
	 <20050428220839.GA5183@mail.shareable.org>
Content-Type: text/plain
Organization: IBM 
Message-Id: <1114761430.4180.1566.camel@localhost>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 
Date: Fri, 29 Apr 2005 00:57:10 -0700
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, 2005-04-28 at 15:08, Jamie Lokier wrote:
> Ram wrote:
> > > I've looked at the code.  Look in fs/proc/base.c (Linux 2.6.10),
> > > proc_root_link().
> > > 
> > > I don't see anything there to prevent you from traversing to the
> > > mounts in the other namespace.
> > > 
> > > So why is it failing?  Any idea?
> > 
> > Since you are traversing a symlink, you will be traversing the symlink
> > in the context of traversing process's namespace. 
> > 
> > If process 'x' is traversing /proc/y/root , the lookup for the root
> > dentry will happen in the context of process x's  namespace, and not
> > process y's namespace. Hence process 'x' wont really get into
> > the namespace of the process y.
> 
> Lookups don't happen in the context of a namespace.
> 
> They happen in the context of a vfsmnt.  And the switch to a new
> vfsmnt is done by matching against (dentry,parent-vfsmnt) pairs.
> current->namespace is only checked for mount & unmount operations, not
> for path lookups.

Looked deeper into the code, and realized that in procfs, the symlink is
not followed through link_path_walk(). instead it is expected to
return the root vfsmount of the traversed process as you rightly
pointed.

 
> 
> Which means proc_root_link, when it switches to the vfsmnt at the root
> of the other process, should traverse into the tree of vfsmnts which
> make up the other namespace.

Yes. But proc_check_root() in proc_pid_follow_link() is failing the 
traversal, because it is expecting the root vfsmount of the traversed
process to belong to the vfsmount tree of the traversing process.
In other words its expecting them to be both in the same namespace.

The permissions get denied by this code in proc_check_root():

         while (vfsmnt != our_vfsmnt) {
                if (vfsmnt == vfsmnt->mnt_parent)
                        goto out;
                de = vfsmnt->mnt_mountpoint;
                vfsmnt = vfsmnt->mnt_parent;
        }

RP
> -- Jamie


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262678AbVD2ON6@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262678AbVD2ON6 (ORCPT <rfc822;willy@w.ods.org>);
	Fri, 29 Apr 2005 10:13:58 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262698AbVD2ON5
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Fri, 29 Apr 2005 10:13:57 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:3245 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S262678AbVD2ONy (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Fri, 29 Apr 2005 10:13:54 -0400
To: linuxram@us.ibm.com
CC: jamie@shareable.org, ericvh@gmail.com, pavel@ucw.cz,
       viro@parcelfarce.linux.theplanet.co.uk, miklos@szeredi.hu,
       hch@infradead.org, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org, akpm@osdl.org
In-reply-to: <1114761430.4180.1566.camel@localhost> (message from Ram on Fri,
	29 Apr 2005 00:57:10 -0700)
Subject: Re: [PATCH] private mounts
References: <E1DPoCg-0000W0-00@localhost>
	 <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk>
	 <20050424213822.GB9304@mail.shareable.org>
	 <20050425152049.GB2508@elf.ucw.cz>
	 <20050425190734.GB28294@mail.shareable.org>
	 <20050426092924.GA4175@elf.ucw.cz>
	 <20050426140715.GA10833@mail.shareable.org>
	 <a4e6962a050428064774e88f4a@mail.gmail.com>
	 <20050428192048.GA2895@mail.shareable.org>
	 <1114717183.4180.718.camel@localhost>
	 <20050428220839.GA5183@mail.shareable.org> <1114761430.4180.1566.camel@localhost>
Message-Id: <E1DRWEt-000149-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Fri, 29 Apr 2005 16:13:07 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> > 
> > Which means proc_root_link, when it switches to the vfsmnt at the root
> > of the other process, should traverse into the tree of vfsmnts which
> > make up the other namespace.
> 
> Yes. But proc_check_root() in proc_pid_follow_link() is failing the 
> traversal, because it is expecting the root vfsmount of the traversed
> process to belong to the vfsmount tree of the traversing process.
> In other words its expecting them to be both in the same namespace.
> 
> The permissions get denied by this code in proc_check_root():
> 

Removing the check makes chroot enter the tree under the other
process's namespace.  However it does not actually change the
namespace, hence mount/umount won't work.

So joinig a namespace does need a new syscall unfortunately.

Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S262770AbVD2Ook@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S262770AbVD2Ook (ORCPT <rfc822;willy@w.ods.org>);
	Fri, 29 Apr 2005 10:44:40 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262755AbVD2Ooa
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Fri, 29 Apr 2005 10:44:30 -0400
Received: from mail.shareable.org ([81.29.64.88]:7083 "EHLO mail.shareable.org")
	by vger.kernel.org with ESMTP id S262762AbVD2OnV (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 29 Apr 2005 10:43:21 -0400
Date: Fri, 29 Apr 2005 15:42:52 +0100
From: Jamie Lokier <jamie@shareable.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: linuxram@us.ibm.com, ericvh@gmail.com, pavel@ucw.cz,
       viro@parcelfarce.linux.theplanet.co.uk, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050429144252.GA17263@mail.shareable.org>
References: <20050425152049.GB2508@elf.ucw.cz> <20050425190734.GB28294@mail.shareable.org> <20050426092924.GA4175@elf.ucw.cz> <20050426140715.GA10833@mail.shareable.org> <a4e6962a050428064774e88f4a@mail.gmail.com> <20050428192048.GA2895@mail.shareable.org> <1114717183.4180.718.camel@localhost> <20050428220839.GA5183@mail.shareable.org> <1114761430.4180.1566.camel@localhost> <E1DRWEt-000149-00@dorka.pomaz.szeredi.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1DRWEt-000149-00@dorka.pomaz.szeredi.hu>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Miklos Szeredi wrote:
> Removing the check makes chroot enter the tree under the other
> process's namespace.  However it does not actually change the
> namespace, hence mount/umount won't work.
> 
> So joinig a namespace does need a new syscall unfortunately.

It would be trivial to copy mnt->mnt_namespace to current->namespace
in set_fs_root.  No need for a syscall just for that.

Given that it works, the right place to decide whether it's allowed is
the permissions on /proc/NNN/root.  But remember that you can already
access another process' namespace using ptrace on that process, so
this doesn't relax security if /proc/NNN/root can be entered whenever
ptrace is allowed.

I would really like to know what the purpose of check_mnt() is in
namespace.c.  In standard kernels you can't enter another process'
namespace (without the change you tried in proc/base.c), so I don't see
how check_mnt() can _ever_ fail.  Can it?

And if it can't fail, is there any need for current->namespace, or can
it just be removed?

-- Jamie

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261157AbVD3IdW@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261157AbVD3IdW (ORCPT <rfc822;willy@w.ods.org>);
	Sat, 30 Apr 2005 04:33:22 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261158AbVD3IdV
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sat, 30 Apr 2005 04:33:21 -0400
Received: from pentafluge.infradead.org ([213.146.154.40]:14766 "EHLO
	pentafluge.infradead.org") by vger.kernel.org with ESMTP
	id S261155AbVD3IdR (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sat, 30 Apr 2005 04:33:17 -0400
Date: Sat, 30 Apr 2005 09:33:13 +0100
From: Christoph Hellwig <hch@infradead.org>
To: Jamie Lokier <jamie@shareable.org>
Cc: Pavel Machek <pavel@ucw.cz>,
       Al Viro <viro@parcelfarce.linux.theplanet.co.uk>,
       Miklos Szeredi <miklos@szeredi.hu>, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050430083313.GB23253@infradead.org>
Mail-Followup-To: Christoph Hellwig <hch@infradead.org>,
	Jamie Lokier <jamie@shareable.org>, Pavel Machek <pavel@ucw.cz>,
	Al Viro <viro@parcelfarce.linux.theplanet.co.uk>,
	Miklos Szeredi <miklos@szeredi.hu>, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, akpm@osdl.org
References: <E1DPnOn-0000T0-00@localhost> <20050424201820.GA28428@infradead.org> <E1DPo3I-0000V0-00@localhost> <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk> <E1DPoCg-0000W0-00@localhost> <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk> <20050424213822.GB9304@mail.shareable.org> <20050425152049.GB2508@elf.ucw.cz> <20050425190734.GB28294@mail.shareable.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050425190734.GB28294@mail.shareable.org>
User-Agent: Mutt/1.4.1i
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> by pentafluge.infradead.org
	See http://www.infradead.org/rpr.html
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Apr 25, 2005 at 08:07:34PM +0100, Jamie Lokier wrote:
> Pavel Machek wrote:
> > > > ... is the same as for the same question with "set of mounts" replaced
> > > > with "environment variables".
> > > 
> > > Not quite.
> > > 
> > > After changing environment variables in .profile, you can copy them to
> > > other shells using ". ~/.profile".
> > > 
> > > There is no analogous mechanism to copy namespaces.
> > 
> > Actually, after you add right mount xyzzy /foo lines into .profile,
> > you can just . ~/.profile ;-).
> 
> Is there a mount command that can do that?  We're talking about
> private mounts - invisible to other namespaces, which includes the
> other shells.
> 
> If there was a /proc/NNN/namespace, that would do the trick :)

I don't think you need a /proc/NNN/namespace, /proc/NNN/mounts already
contains a mount table.  It's pretty trivial to write a small shellscript
to parse that, compare with the current namespace and do all mount/umounts
to make them fit the other processes namespace.  Real problem here are
filesystems that don't implement ->show_options or do so only partially
so that some options are lost.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261161AbVD3IfY@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261161AbVD3IfY (ORCPT <rfc822;willy@w.ods.org>);
	Sat, 30 Apr 2005 04:35:24 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261159AbVD3IfY
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sat, 30 Apr 2005 04:35:24 -0400
Received: from pentafluge.infradead.org ([213.146.154.40]:17838 "EHLO
	pentafluge.infradead.org") by vger.kernel.org with ESMTP
	id S261158AbVD3IfR (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sat, 30 Apr 2005 04:35:17 -0400
Date: Sat, 30 Apr 2005 09:35:16 +0100
From: Christoph Hellwig <hch@infradead.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: bulb@ucw.cz, viro@parcelfarce.linux.theplanet.co.uk, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050430083516.GC23253@infradead.org>
Mail-Followup-To: Christoph Hellwig <hch@infradead.org>,
	Miklos Szeredi <miklos@szeredi.hu>, bulb@ucw.cz,
	viro@parcelfarce.linux.theplanet.co.uk,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	akpm@osdl.org
References: <20050424201820.GA28428@infradead.org> <E1DPo3I-0000V0-00@localhost> <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk> <E1DPoCg-0000W0-00@localhost> <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk> <E1DPoRz-0000Y0-00@localhost> <20050424211942.GN13052@parcelfarce.linux.theplanet.co.uk> <E1DPofK-0000Yu-00@localhost> <20050425071047.GA13975@vagabond> <E1DQ0Mc-0007B5-00@dorka.pomaz.szeredi.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1DQ0Mc-0007B5-00@dorka.pomaz.szeredi.hu>
User-Agent: Mutt/1.4.1i
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> by pentafluge.infradead.org
	See http://www.infradead.org/rpr.html
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Apr 25, 2005 at 11:58:50AM +0200, Miklos Szeredi wrote:
> > I can't write a script that reads your mind. But I sure can write
> > a script that finds out what you mounted in the other shells (with help
> > of a little wrapper around the mount command).
> 
> How do you bind mount it from a different namespace?  You _do_ need
> bind mount, since a new mount might require password input, etc...

Not nessecarily.  The filesystem gets called into ->get_sb for every mount,
and can then decided whether to return an existing superblock instance or
setup a new one.  If the credentials for the new mount match an old one
it can just reuse it.  (e.g. for block based filesystem it will always reuse
right now)


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261165AbVD3Ih6@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261165AbVD3Ih6 (ORCPT <rfc822;willy@w.ods.org>);
	Sat, 30 Apr 2005 04:37:58 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261163AbVD3Ih6
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sat, 30 Apr 2005 04:37:58 -0400
Received: from pentafluge.infradead.org ([213.146.154.40]:20142 "EHLO
	pentafluge.infradead.org") by vger.kernel.org with ESMTP
	id S261159AbVD3Ihr (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sat, 30 Apr 2005 04:37:47 -0400
Date: Sat, 30 Apr 2005 09:37:42 +0100
From: Christoph Hellwig <hch@infradead.org>
To: Olivier Galibert <galibert@pobox.com>, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050430083742.GD23253@infradead.org>
Mail-Followup-To: Christoph Hellwig <hch@infradead.org>,
	Olivier Galibert <galibert@pobox.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
References: <E1DPnOn-0000T0-00@localhost> <20050424201820.GA28428@infradead.org> <E1DPo3I-0000V0-00@localhost> <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk> <E1DPoCg-0000W0-00@localhost> <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk> <E1DPoRz-0000Y0-00@localhost> <20050424211942.GN13052@parcelfarce.linux.theplanet.co.uk> <20050425094804.GA33040@dspnet.fr.eu.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050425094804.GA33040@dspnet.fr.eu.org>
User-Agent: Mutt/1.4.1i
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> by pentafluge.infradead.org
	See http://www.infradead.org/rpr.html
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Apr 25, 2005 at 11:48:04AM +0200, Olivier Galibert wrote:
> On Sun, Apr 24, 2005 at 10:19:42PM +0100, Al Viro wrote:
> > Of course you can.  It does execute the obvious set of rc files.
> 
> Is there a possibility for a process to change its namespace to
> another existing one?  That would be needed to have a per-user
> namespace you go to from rc files or pam.

It is not right now, and I don't think joining a namespace is a concept
that fits very well into our architecture.  What does make sense is an
unshare() syscall that takes the CLONE_* argument and unshares those in
the current process from the parent without creating a new process.  Then
you can easily reproduce another namespace by value instead of by reference.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261169AbVD3J0Z@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261169AbVD3J0Z (ORCPT <rfc822;willy@w.ods.org>);
	Sat, 30 Apr 2005 05:26:25 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261168AbVD3J0Z
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sat, 30 Apr 2005 05:26:25 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:25776 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S261169AbVD3J0P (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sat, 30 Apr 2005 05:26:15 -0400
To: hch@infradead.org
CC: bulb@ucw.cz, viro@parcelfarce.linux.theplanet.co.uk, hch@infradead.org,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
In-reply-to: <20050430083516.GC23253@infradead.org> (message from Christoph
	Hellwig on Sat, 30 Apr 2005 09:35:16 +0100)
Subject: Re: [PATCH] private mounts
References: <20050424201820.GA28428@infradead.org> <E1DPo3I-0000V0-00@localhost> <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk> <E1DPoCg-0000W0-00@localhost> <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk> <E1DPoRz-0000Y0-00@localhost> <20050424211942.GN13052@parcelfarce.linux.theplanet.co.uk> <E1DPofK-0000Yu-00@localhost> <20050425071047.GA13975@vagabond> <E1DQ0Mc-0007B5-00@dorka.pomaz.szeredi.hu> <20050430083516.GC23253@infradead.org>
Message-Id: <E1DRoDm-0002G9-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Sat, 30 Apr 2005 11:25:10 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> > > I can't write a script that reads your mind. But I sure can write
> > > a script that finds out what you mounted in the other shells (with help
> > > of a little wrapper around the mount command).
> > 
> > How do you bind mount it from a different namespace?  You _do_ need
> > bind mount, since a new mount might require password input, etc...
> 
> Not nessecarily.  The filesystem gets called into ->get_sb for every mount,
> and can then decided whether to return an existing superblock instance or
> setup a new one.  If the credentials for the new mount match an old one
> it can just reuse it.  (e.g. for block based filesystem it will always reuse
> right now)

And if the credentials are checked in userspace (sshfs)?

Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261173AbVD3JnY@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261173AbVD3JnY (ORCPT <rfc822;willy@w.ods.org>);
	Sat, 30 Apr 2005 05:43:24 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261171AbVD3JnX
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sat, 30 Apr 2005 05:43:23 -0400
Received: from mail.shareable.org ([81.29.64.88]:37035 "EHLO
	mail.shareable.org") by vger.kernel.org with ESMTP id S261174AbVD3JnN
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sat, 30 Apr 2005 05:43:13 -0400
Date: Sat, 30 Apr 2005 10:42:18 +0100
From: Jamie Lokier <jamie@shareable.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: hch@infradead.org, bulb@ucw.cz, viro@parcelfarce.linux.theplanet.co.uk,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050430094218.GA32679@mail.shareable.org>
References: <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk> <E1DPoCg-0000W0-00@localhost> <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk> <E1DPoRz-0000Y0-00@localhost> <20050424211942.GN13052@parcelfarce.linux.theplanet.co.uk> <E1DPofK-0000Yu-00@localhost> <20050425071047.GA13975@vagabond> <E1DQ0Mc-0007B5-00@dorka.pomaz.szeredi.hu> <20050430083516.GC23253@infradead.org> <E1DRoDm-0002G9-00@dorka.pomaz.szeredi.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1DRoDm-0002G9-00@dorka.pomaz.szeredi.hu>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Miklos Szeredi wrote:
> > > How do you bind mount it from a different namespace?  You _do_ need
> > > bind mount, since a new mount might require password input, etc...
> > 
> > Not nessecarily.  The filesystem gets called into ->get_sb for every mount,
> > and can then decided whether to return an existing superblock instance or
> > setup a new one.  If the credentials for the new mount match an old one
> > it can just reuse it.  (e.g. for block based filesystem it will always reuse
> > right now)
> 
> And if the credentials are checked in userspace (sshfs)?

Well, if you can find a way to tell the userspace FUSE daemon to know
that the mount is being done by the same user as the existing mount,
you don't need (or want) to check the credentials - you want the FUSE
daemon to tell the kernel code which superblock to reuse.

This hack is a bit nasty - namespace per login, copying mounts
from another login's namespace - but it would work.

-- Jamie

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261181AbVD3KQA@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261181AbVD3KQA (ORCPT <rfc822;willy@w.ods.org>);
	Sat, 30 Apr 2005 06:16:00 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261177AbVD3KP7
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sat, 30 Apr 2005 06:15:59 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:32688 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S261181AbVD3KO2 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sat, 30 Apr 2005 06:14:28 -0400
To: jamie@shareable.org
CC: hch@infradead.org, bulb@ucw.cz, viro@parcelfarce.linux.theplanet.co.uk,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
In-reply-to: <20050430094218.GA32679@mail.shareable.org> (message from Jamie
	Lokier on Sat, 30 Apr 2005 10:42:18 +0100)
Subject: Re: [PATCH] private mounts
References: <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk> <E1DPoCg-0000W0-00@localhost> <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk> <E1DPoRz-0000Y0-00@localhost> <20050424211942.GN13052@parcelfarce.linux.theplanet.co.uk> <E1DPofK-0000Yu-00@localhost> <20050425071047.GA13975@vagabond> <E1DQ0Mc-0007B5-00@dorka.pomaz.szeredi.hu> <20050430083516.GC23253@infradead.org> <E1DRoDm-0002G9-00@dorka.pomaz.szeredi.hu> <20050430094218.GA32679@mail.shareable.org>
Message-Id: <E1DRoz9-0002JL-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Sat, 30 Apr 2005 12:14:07 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> Well, if you can find a way to tell the userspace FUSE daemon to know
> that the mount is being done by the same user as the existing mount,
> you don't need (or want) to check the credentials - you want the FUSE
> daemon to tell the kernel code which superblock to reuse.

It sounds very _very_ complicated compared to just using bind mounts.

And maybe the user _does_ want a new connection to the same server
(for whatever reason).  Why should we _force_ a sharing of
superblocks?

Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261235AbVD3Oge@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261235AbVD3Oge (ORCPT <rfc822;willy@w.ods.org>);
	Sat, 30 Apr 2005 10:36:34 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261238AbVD3Oge
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sat, 30 Apr 2005 10:36:34 -0400
Received: from mail.shareable.org ([81.29.64.88]:44715 "EHLO
	mail.shareable.org") by vger.kernel.org with ESMTP id S261235AbVD3Og2
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sat, 30 Apr 2005 10:36:28 -0400
Date: Sat, 30 Apr 2005 15:36:09 +0100
From: Jamie Lokier <jamie@shareable.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: hch@infradead.org, bulb@ucw.cz, viro@parcelfarce.linux.theplanet.co.uk,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050430143609.GA4362@mail.shareable.org>
References: <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk> <E1DPoRz-0000Y0-00@localhost> <20050424211942.GN13052@parcelfarce.linux.theplanet.co.uk> <E1DPofK-0000Yu-00@localhost> <20050425071047.GA13975@vagabond> <E1DQ0Mc-0007B5-00@dorka.pomaz.szeredi.hu> <20050430083516.GC23253@infradead.org> <E1DRoDm-0002G9-00@dorka.pomaz.szeredi.hu> <20050430094218.GA32679@mail.shareable.org> <E1DRoz9-0002JL-00@dorka.pomaz.szeredi.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1DRoz9-0002JL-00@dorka.pomaz.szeredi.hu>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Miklos Szeredi wrote:
> > Well, if you can find a way to tell the userspace FUSE daemon to know
> > that the mount is being done by the same user as the existing mount,
> > you don't need (or want) to check the credentials - you want the FUSE
> > daemon to tell the kernel code which superblock to reuse.
> 
> It sounds very _very_ complicated compared to just using bind mounts.
> 
> And maybe the user _does_ want a new connection to the same server
> (for whatever reason).  Why should we _force_ a sharing of
> superblocks?

The point is that you can decide whether to do that in userspace.
It's up to whatever code you put in the _userspace_ FUSE commands.

No kernel support for bind mounts from another namespace is required.

Actually, in terms of complexity, it's not much different from using
bind mounts.  Either way involves finding all the mounts of another
session and copying them one by one: either by getting confirmation
from the daemon to attach to the same superblock, or by getting
handles from the daemon for all the individual directories to bind
mount.

In all, I think private namespaces are still the cleaner way to do it
_when_ a user wants their mounts to appear in multiple sessions anyway.

But bind mounts or superblock sharing are more flexible, at the same
time as being more cumbersome as a user interface.

-- JAmie

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261273AbVD3QAj@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261273AbVD3QAj (ORCPT <rfc822;willy@w.ods.org>);
	Sat, 30 Apr 2005 12:00:39 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261271AbVD3QAi
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sat, 30 Apr 2005 12:00:38 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:37809 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S261270AbVD3QAc (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sat, 30 Apr 2005 12:00:32 -0400
To: jamie@shareable.org
CC: hch@infradead.org, bulb@ucw.cz, viro@parcelfarce.linux.theplanet.co.uk,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
In-reply-to: <20050430143609.GA4362@mail.shareable.org> (message from Jamie
	Lokier on Sat, 30 Apr 2005 15:36:09 +0100)
Subject: Re: [PATCH] private mounts
References: <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk> <E1DPoRz-0000Y0-00@localhost> <20050424211942.GN13052@parcelfarce.linux.theplanet.co.uk> <E1DPofK-0000Yu-00@localhost> <20050425071047.GA13975@vagabond> <E1DQ0Mc-0007B5-00@dorka.pomaz.szeredi.hu> <20050430083516.GC23253@infradead.org> <E1DRoDm-0002G9-00@dorka.pomaz.szeredi.hu> <20050430094218.GA32679@mail.shareable.org> <E1DRoz9-0002JL-00@dorka.pomaz.szeredi.hu> <20050430143609.GA4362@mail.shareable.org>
Message-Id: <E1DRuNU-0002el-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Sat, 30 Apr 2005 17:59:36 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> Actually, in terms of complexity, it's not much different from using
> bind mounts.

As has been suggested by Pavel, bind mounting foreign namespaces could
just be done with a new bind_fd(fd, path) syscall and file descriptor
passing with SCM_RIGHTS.

That sounds to me orders of magnitude less complex (on the kernel side
at least) than sb sharing.

Miklos




From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261287AbVD3Qop@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261287AbVD3Qop (ORCPT <rfc822;willy@w.ods.org>);
	Sat, 30 Apr 2005 12:44:45 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261289AbVD3Qn3
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sat, 30 Apr 2005 12:43:29 -0400
Received: from mail.shareable.org ([81.29.64.88]:51627 "EHLO
	mail.shareable.org") by vger.kernel.org with ESMTP id S261286AbVD3QnJ
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sat, 30 Apr 2005 12:43:09 -0400
Date: Sat, 30 Apr 2005 17:42:58 +0100
From: Jamie Lokier <jamie@shareable.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: hch@infradead.org, bulb@ucw.cz, viro@parcelfarce.linux.theplanet.co.uk,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050430164258.GA6498@mail.shareable.org>
References: <20050424211942.GN13052@parcelfarce.linux.theplanet.co.uk> <E1DPofK-0000Yu-00@localhost> <20050425071047.GA13975@vagabond> <E1DQ0Mc-0007B5-00@dorka.pomaz.szeredi.hu> <20050430083516.GC23253@infradead.org> <E1DRoDm-0002G9-00@dorka.pomaz.szeredi.hu> <20050430094218.GA32679@mail.shareable.org> <E1DRoz9-0002JL-00@dorka.pomaz.szeredi.hu> <20050430143609.GA4362@mail.shareable.org> <E1DRuNU-0002el-00@dorka.pomaz.szeredi.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1DRuNU-0002el-00@dorka.pomaz.szeredi.hu>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Miklos Szeredi wrote:
> > Actually, in terms of complexity, it's not much different from using
> > bind mounts.
> 
> As has been suggested by Pavel, bind mounting foreign namespaces could
> just be done with a new bind_fd(fd, path) syscall and file descriptor
> passing with SCM_RIGHTS.

Yes, he's right.

But you don't need a new system call to bind an fd.

"mount --bind /proc/self/fd/N mount_point" works, try it.

> That sounds to me orders of magnitude less complex (on the kernel side
> at least) than sb sharing.

In terms of what happens in the kernel, they're almost exactly the
same: either way, a super block ends up shared by two mounts.  That's
what I meant.

I agree that in terms of what userspace has to do, if just binding
works that's simpler.  And it does seem to work with the above mount
command.

-- Jamie

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261293AbVD3QtA@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261293AbVD3QtA (ORCPT <rfc822;willy@w.ods.org>);
	Sat, 30 Apr 2005 12:49:00 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261294AbVD3Qrt
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sat, 30 Apr 2005 12:47:49 -0400
Received: from e35.co.us.ibm.com ([32.97.110.133]:63164 "EHLO
	e35.co.us.ibm.com") by vger.kernel.org with ESMTP id S261291AbVD3QrL
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sat, 30 Apr 2005 12:47:11 -0400
Subject: Re: [PATCH] private mounts
From: Ram <linuxram@us.ibm.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Jamie Lokier <jamie@shareable.org>, Pavel Machek <pavel@ucw.cz>,
       Al Viro <viro@parcelfarce.linux.theplanet.co.uk>,
       Miklos Szeredi <miklos@szeredi.hu>, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>
In-Reply-To: <20050430083313.GB23253@infradead.org>
References: <E1DPnOn-0000T0-00@localhost>
	 <20050424201820.GA28428@infradead.org> <E1DPo3I-0000V0-00@localhost>
	 <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk>
	 <E1DPoCg-0000W0-00@localhost>
	 <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk>
	 <20050424213822.GB9304@mail.shareable.org>
	 <20050425152049.GB2508@elf.ucw.cz>
	 <20050425190734.GB28294@mail.shareable.org>
	 <20050430083313.GB23253@infradead.org>
Content-Type: text/plain
Organization: IBM 
Message-Id: <1114879626.4180.2093.camel@localhost>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 
Date: Sat, 30 Apr 2005 09:47:06 -0700
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Sat, 2005-04-30 at 01:33, Christoph Hellwig wrote:
> On Mon, Apr 25, 2005 at 08:07:34PM +0100, Jamie Lokier wrote:
> > Pavel Machek wrote:
> > > > > ... is the same as for the same question with "set of mounts" replaced
> > > > > with "environment variables".
> > > > 
> > > > Not quite.
> > > > 
> > > > After changing environment variables in .profile, you can copy them to
> > > > other shells using ". ~/.profile".
> > > > 
> > > > There is no analogous mechanism to copy namespaces.
> > > 
> > > Actually, after you add right mount xyzzy /foo lines into .profile,
> > > you can just . ~/.profile ;-).
> > 
> > Is there a mount command that can do that?  We're talking about
> > private mounts - invisible to other namespaces, which includes the
> > other shells.
> > 
> > If there was a /proc/NNN/namespace, that would do the trick :)
> 
> I don't think you need a /proc/NNN/namespace, /proc/NNN/mounts already
> contains a mount table.  It's pretty trivial to write a small shellscript
> to parse that, compare with the current namespace and do all mount/umounts
> to make them fit the other processes namespace.  Real problem here are
> filesystems that don't implement ->show_options or do so only partially
> so that some options are lost.

The other problem is: How would new mounts  in any of these namespaces
propogate to other namespaces owned by the same user? 

I mean, how will the other namespace's belonging to the same user, be
able to pull the mounts into their namespaces?  shared subtree won't be
a solution because these namespaces won't have a parent-child
relationship to begin with, for the propogation to be set up.


RP



> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261311AbVD3RId@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261311AbVD3RId (ORCPT <rfc822;willy@w.ods.org>);
	Sat, 30 Apr 2005 13:08:33 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261306AbVD3RId
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sat, 30 Apr 2005 13:08:33 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:58033 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S261305AbVD3RI3 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sat, 30 Apr 2005 13:08:29 -0400
To: jamie@shareable.org
CC: hch@infradead.org, bulb@ucw.cz, viro@parcelfarce.linux.theplanet.co.uk,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
In-reply-to: <20050430164258.GA6498@mail.shareable.org> (message from Jamie
	Lokier on Sat, 30 Apr 2005 17:42:58 +0100)
Subject: Re: [PATCH] private mounts
References: <20050424211942.GN13052@parcelfarce.linux.theplanet.co.uk> <E1DPofK-0000Yu-00@localhost> <20050425071047.GA13975@vagabond> <E1DQ0Mc-0007B5-00@dorka.pomaz.szeredi.hu> <20050430083516.GC23253@infradead.org> <E1DRoDm-0002G9-00@dorka.pomaz.szeredi.hu> <20050430094218.GA32679@mail.shareable.org> <E1DRoz9-0002JL-00@dorka.pomaz.szeredi.hu> <20050430143609.GA4362@mail.shareable.org> <E1DRuNU-0002el-00@dorka.pomaz.szeredi.hu> <20050430164258.GA6498@mail.shareable.org>
Message-Id: <E1DRvRc-0002lq-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Sat, 30 Apr 2005 19:07:56 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> But you don't need a new system call to bind an fd.
> 
> "mount --bind /proc/self/fd/N mount_point" works, try it.

Ahh, yes :)

Still proc_check_root() has to be relaxed, to allow dereferencing link
under a different namespace.  Maybe the check should be skipped for
capable(CAP_SYS_ADMIN) or similar.

What do people think about that?

Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261331AbVD3SUc@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261331AbVD3SUc (ORCPT <rfc822;willy@w.ods.org>);
	Sat, 30 Apr 2005 14:20:32 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261330AbVD3SUc
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sat, 30 Apr 2005 14:20:32 -0400
Received: from dspnet.fr.eu.org ([213.186.44.138]:40200 "EHLO dspnet.fr.eu.org")
	by vger.kernel.org with ESMTP id S261328AbVD3SUY (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sat, 30 Apr 2005 14:20:24 -0400
Date: Sat, 30 Apr 2005 20:20:16 +0200
From: Olivier Galibert <galibert@pobox.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: jamie@shareable.org, hch@infradead.org, bulb@ucw.cz,
       viro@parcelfarce.linux.theplanet.co.uk, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050430182016.GA41358@dspnet.fr.eu.org>
Mail-Followup-To: Olivier Galibert <galibert@pobox.com>,
	Miklos Szeredi <miklos@szeredi.hu>, jamie@shareable.org,
	hch@infradead.org, bulb@ucw.cz,
	viro@parcelfarce.linux.theplanet.co.uk,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	akpm@osdl.org
References: <20050425071047.GA13975@vagabond> <E1DQ0Mc-0007B5-00@dorka.pomaz.szeredi.hu> <20050430083516.GC23253@infradead.org> <E1DRoDm-0002G9-00@dorka.pomaz.szeredi.hu> <20050430094218.GA32679@mail.shareable.org> <E1DRoz9-0002JL-00@dorka.pomaz.szeredi.hu> <20050430143609.GA4362@mail.shareable.org> <E1DRuNU-0002el-00@dorka.pomaz.szeredi.hu> <20050430164258.GA6498@mail.shareable.org> <E1DRvRc-0002lq-00@dorka.pomaz.szeredi.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1DRvRc-0002lq-00@dorka.pomaz.szeredi.hu>
User-Agent: Mutt/1.4.2.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Sat, Apr 30, 2005 at 07:07:56PM +0200, Miklos Szeredi wrote:
> > But you don't need a new system call to bind an fd.
> > 
> > "mount --bind /proc/self/fd/N mount_point" works, try it.
> 
> Ahh, yes :)
> 
> Still proc_check_root() has to be relaxed, to allow dereferencing link
> under a different namespace.  Maybe the check should be skipped for
> capable(CAP_SYS_ADMIN) or similar.
> 
> What do people think about that?

To me it looks like an atrocious hack that works only because of the
way the implementation is done and not really by design.  A well
defined interface where you want to do is explicitely said is way less
annoying long term.  I don't know what the right approach would be
(join <ns> vs. exec in <ns> vs. clone in <ns>) or even what a
namespace reference should look like (fd, pid, something else), and
probably only Al has a good idea of that.  Al, you've been quite
silent here.  What do you think the right method/interface would be to
start an interactive shell in a pre-existing different namespace?

  OG.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261462AbVD3XzR@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261462AbVD3XzR (ORCPT <rfc822;willy@w.ods.org>);
	Sat, 30 Apr 2005 19:55:17 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261468AbVD3XzQ
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sat, 30 Apr 2005 19:55:16 -0400
Received: from mail.shareable.org ([81.29.64.88]:3244 "EHLO mail.shareable.org")
	by vger.kernel.org with ESMTP id S261462AbVD3XzH (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sat, 30 Apr 2005 19:55:07 -0400
Date: Sun, 1 May 2005 00:54:54 +0100
From: Jamie Lokier <jamie@shareable.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: hch@infradead.org, bulb@ucw.cz, viro@parcelfarce.linux.theplanet.co.uk,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050430235453.GA11494@mail.shareable.org>
References: <20050425071047.GA13975@vagabond> <E1DQ0Mc-0007B5-00@dorka.pomaz.szeredi.hu> <20050430083516.GC23253@infradead.org> <E1DRoDm-0002G9-00@dorka.pomaz.szeredi.hu> <20050430094218.GA32679@mail.shareable.org> <E1DRoz9-0002JL-00@dorka.pomaz.szeredi.hu> <20050430143609.GA4362@mail.shareable.org> <E1DRuNU-0002el-00@dorka.pomaz.szeredi.hu> <20050430164258.GA6498@mail.shareable.org> <E1DRvRc-0002lq-00@dorka.pomaz.szeredi.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1DRvRc-0002lq-00@dorka.pomaz.szeredi.hu>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Miklos Szeredi wrote:
> > But you don't need a new system call to bind an fd.
> > 
> > "mount --bind /proc/self/fd/N mount_point" works, try it.
> 
> Ahh, yes :)
> 
> Still proc_check_root() has to be relaxed, to allow dereferencing link
> under a different namespace.

Not necessary.

Why not have the FUSE daemon keep open a file descriptor for the
directory it's mounted on, and have it sent that to new would-be
mounters of the same directory using a unix domain socket (rather as
Pavel suggested)?

> Maybe the check should be skipped for
> capable(CAP_SYS_ADMIN) or similar.

No.  The check is to prevent processes in chroot jails from accessing
directories outside their jail.  Even CAP_SYS_ADMIN processes must be
forbidden from doing that.

But proc_check_root is unnecessarily strict, in that it prevents a
process from traversing into a "child" namespace.

IMHO, a better security restriction anyway would be for processes in
chroot jails to not be able to see processes outside the jail in /proc
- only processes inside the jail should be visible.  I think everyone
agrees that would be best.

If that were implemented, then proc_check_root would be redundant and
could be removed entirely.

-- Jamie

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261468AbVD3X6n@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261468AbVD3X6n (ORCPT <rfc822;willy@w.ods.org>);
	Sat, 30 Apr 2005 19:58:43 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261471AbVD3X6n
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sat, 30 Apr 2005 19:58:43 -0400
Received: from mail.shareable.org ([81.29.64.88]:5292 "EHLO mail.shareable.org")
	by vger.kernel.org with ESMTP id S261468AbVD3X6g (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sat, 30 Apr 2005 19:58:36 -0400
Date: Sun, 1 May 2005 00:58:29 +0100
From: Jamie Lokier <jamie@shareable.org>
To: Olivier Galibert <galibert@pobox.com>, Miklos Szeredi <miklos@szeredi.hu>,
       hch@infradead.org, bulb@ucw.cz, viro@parcelfarce.linux.theplanet.co.uk,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050430235829.GB11494@mail.shareable.org>
References: <E1DQ0Mc-0007B5-00@dorka.pomaz.szeredi.hu> <20050430083516.GC23253@infradead.org> <E1DRoDm-0002G9-00@dorka.pomaz.szeredi.hu> <20050430094218.GA32679@mail.shareable.org> <E1DRoz9-0002JL-00@dorka.pomaz.szeredi.hu> <20050430143609.GA4362@mail.shareable.org> <E1DRuNU-0002el-00@dorka.pomaz.szeredi.hu> <20050430164258.GA6498@mail.shareable.org> <E1DRvRc-0002lq-00@dorka.pomaz.szeredi.hu> <20050430182016.GA41358@dspnet.fr.eu.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050430182016.GA41358@dspnet.fr.eu.org>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

Olivier Galibert wrote:
> > > "mount --bind /proc/self/fd/N mount_point" works, try it.
> > 
> > What do people think about that?
> 
> To me it looks like an atrocious hack that works only because of the
> way the implementation is done and not really by design.

>>From fs/namespace.c:do_loopback, the function which does bind mounts:

	if (check_mnt(nd->mnt) && (!recurse || check_mnt(old_nd.mnt))) {

check_mnt() verifies that a mountpoint is in the same namespace as the
current process.  recurse is set for --rbind mounts, but not --bind mounts.

Notice how old_nd.mnt is explicitly _not_ checked for being in the current
namespace when doing --bind?

That says to me that Al thought about this case, and coded for it...

(I'm still not clear why the check_mnt() calls are needed at all, though).

-- Jamie

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261518AbVEACkA@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261518AbVEACkA (ORCPT <rfc822;willy@w.ods.org>);
	Sat, 30 Apr 2005 22:40:00 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261517AbVEACkA
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sat, 30 Apr 2005 22:40:00 -0400
Received: from e4.ny.us.ibm.com ([32.97.182.144]:50819 "EHLO e4.ny.us.ibm.com")
	by vger.kernel.org with ESMTP id S261516AbVEACjy (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sat, 30 Apr 2005 22:39:54 -0400
Subject: Re: [PATCH] private mounts
From: Ram <linuxram@us.ibm.com>
To: Jamie Lokier <jamie@shareable.org>
Cc: Olivier Galibert <galibert@pobox.com>, Miklos Szeredi <miklos@szeredi.hu>,
       hch@infradead.org, bulb@ucw.cz, viro@parcelfarce.linux.theplanet.co.uk,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       Andrew Morton <akpm@osdl.org>
In-Reply-To: <20050430235829.GB11494@mail.shareable.org>
References: <E1DQ0Mc-0007B5-00@dorka.pomaz.szeredi.hu>
	 <20050430083516.GC23253@infradead.org>
	 <E1DRoDm-0002G9-00@dorka.pomaz.szeredi.hu>
	 <20050430094218.GA32679@mail.shareable.org>
	 <E1DRoz9-0002JL-00@dorka.pomaz.szeredi.hu>
	 <20050430143609.GA4362@mail.shareable.org>
	 <E1DRuNU-0002el-00@dorka.pomaz.szeredi.hu>
	 <20050430164258.GA6498@mail.shareable.org>
	 <E1DRvRc-0002lq-00@dorka.pomaz.szeredi.hu>
	 <20050430182016.GA41358@dspnet.fr.eu.org>
	 <20050430235829.GB11494@mail.shareable.org>
Content-Type: text/plain
Organization: IBM 
Message-Id: <1114915182.4180.2110.camel@localhost>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 
Date: Sat, 30 Apr 2005 19:39:43 -0700
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Sat, 2005-04-30 at 16:58, Jamie Lokier wrote:
> Olivier Galibert wrote:
> > > > "mount --bind /proc/self/fd/N mount_point" works, try it.
> > > 
> > > What do people think about that?
> > 
> > To me it looks like an atrocious hack that works only because of the
> > way the implementation is done and not really by design.
> 
> >From fs/namespace.c:do_loopback, the function which does bind mounts:
> 
> 	if (check_mnt(nd->mnt) && (!recurse || check_mnt(old_nd.mnt))) {
> 
> check_mnt() verifies that a mountpoint is in the same namespace as the
> current process.  recurse is set for --rbind mounts, but not --bind mounts.
> 
> Notice how old_nd.mnt is explicitly _not_ checked for being in the current
> namespace when doing --bind?

> That says to me that Al thought about this case, and coded for it...
> 
> (I'm still not clear why the check_mnt() calls are needed at all, though).
> 
Making a wild guess.

What if some filesystem allowed access to vfsmount in other namespace?
Just like the proc filesystem having the ability to do so, but
marginally stops it through the check in proc_check_root().

However the check you mentioned above where-a-bind-mount-across-
namespace is allowed, implies that there is some legal way of getting
access to vfsmounts in other namespace.  Or maybe a remote possibility
that its a bug?

RP


> -- Jamie
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261545AbVEAF4z@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261545AbVEAF4z (ORCPT <rfc822;willy@w.ods.org>);
	Sun, 1 May 2005 01:56:55 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261544AbVEAF4y
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 1 May 2005 01:56:54 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:32691 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S261538AbVEAF4u (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sun, 1 May 2005 01:56:50 -0400
To: jamie@shareable.org
CC: hch@infradead.org, bulb@ucw.cz, viro@parcelfarce.linux.theplanet.co.uk,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
In-reply-to: <20050430235453.GA11494@mail.shareable.org> (message from Jamie
	Lokier on Sun, 1 May 2005 00:54:54 +0100)
Subject: Re: [PATCH] private mounts
References: <20050425071047.GA13975@vagabond> <E1DQ0Mc-0007B5-00@dorka.pomaz.szeredi.hu> <20050430083516.GC23253@infradead.org> <E1DRoDm-0002G9-00@dorka.pomaz.szeredi.hu> <20050430094218.GA32679@mail.shareable.org> <E1DRoz9-0002JL-00@dorka.pomaz.szeredi.hu> <20050430143609.GA4362@mail.shareable.org> <E1DRuNU-0002el-00@dorka.pomaz.szeredi.hu> <20050430164258.GA6498@mail.shareable.org> <E1DRvRc-0002lq-00@dorka.pomaz.szeredi.hu> <20050430235453.GA11494@mail.shareable.org>
Message-Id: <E1DS7RB-0004Md-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Sun, 01 May 2005 07:56:17 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> Not necessary.
> 
> Why not have the FUSE daemon keep open a file descriptor for the
> directory it's mounted on, and have it sent that to new would-be
> mounters of the same directory using a unix domain socket (rather as
> Pavel suggested)?

How does that help?  It doesn't matter _which_ process you try to bind
mount /proc/XXX/fd/N from, the result will be the same.

> No.  The check is to prevent processes in chroot jails from accessing
> directories outside their jail.  Even CAP_SYS_ADMIN processes must be
> forbidden from doing that.

As someone pointed out, CAP_SYS_ADMIN processes can already escape the
chroot jail with CLONE_NEWNS.  (fd=open("."); clone(CLONE_NEWNS);
[child:] fchdir(fd); chdir(".."))

> But proc_check_root is unnecessarily strict, in that it prevents a
> process from traversing into a "child" namespace.
> 
> IMHO, a better security restriction anyway would be for processes in
> chroot jails to not be able to see processes outside the jail in /proc
> - only processes inside the jail should be visible.  I think everyone
> agrees that would be best.

Dunno.  It's a big change possibly breaking existing applications.
Chroot probably has other uses than jailing.

> If that were implemented, then proc_check_root would be redundant and
> could be removed entirely.

Yes. 

Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261549AbVEAGjs@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261549AbVEAGjs (ORCPT <rfc822;willy@w.ods.org>);
	Sun, 1 May 2005 02:39:48 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261548AbVEAGjr
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 1 May 2005 02:39:47 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:42163 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S261320AbVEAGjp (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sun, 1 May 2005 02:39:45 -0400
To: jamie@shareable.org
CC: hch@infradead.org, bulb@ucw.cz, viro@parcelfarce.linux.theplanet.co.uk,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
In-reply-to: <E1DS7RB-0004Md-00@dorka.pomaz.szeredi.hu> (message from Miklos
	Szeredi on Sun, 01 May 2005 07:56:17 +0200)
Subject: Re: [PATCH] private mounts
References: <20050425071047.GA13975@vagabond> <E1DQ0Mc-0007B5-00@dorka.pomaz.szeredi.hu> <20050430083516.GC23253@infradead.org> <E1DRoDm-0002G9-00@dorka.pomaz.szeredi.hu> <20050430094218.GA32679@mail.shareable.org> <E1DRoz9-0002JL-00@dorka.pomaz.szeredi.hu> <20050430143609.GA4362@mail.shareable.org> <E1DRuNU-0002el-00@dorka.pomaz.szeredi.hu> <20050430164258.GA6498@mail.shareable.org> <E1DRvRc-0002lq-00@dorka.pomaz.szeredi.hu> <20050430235453.GA11494@mail.shareable.org> <E1DS7RB-0004Md-00@dorka.pomaz.szeredi.hu>
Message-Id: <E1DS86r-0004PD-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Sun, 01 May 2005 08:39:21 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> But proc_check_root is unnecessarily strict, in that it prevents a
> process from traversing into a "child" namespace.
> 
> IMHO, a better security restriction anyway would be for processes in
> chroot jails to not be able to see processes outside the jail in /proc
> - only processes inside the jail should be visible.  I think everyone
> agrees that would be best.

Creating a new namespace would also have the same effect (only
processes using that namespace are visible).  It would be rather ugly,
if a user could not see processes in other login sessions, just
because he uses private namespaces.

Miklos

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261655AbVEAPle@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261655AbVEAPle (ORCPT <rfc822;willy@w.ods.org>);
	Sun, 1 May 2005 11:41:34 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261657AbVEAPle
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 1 May 2005 11:41:34 -0400
Received: from wproxy.gmail.com ([64.233.184.196]:2398 "EHLO wproxy.gmail.com")
	by vger.kernel.org with ESMTP id S261655AbVEAPlb convert rfc822-to-8bit
	(ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sun, 1 May 2005 11:41:31 -0400
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=nCBwSycFhc1B/miFtMQuqlALOeZxxAmibFysgxz9tZboxRF7Mpr+Kzkmd+KH7kLS3aB5az/4a0HiLy3WwDucPtABIgaxRg6owvpRZi7bKUpEcFUqE7aIGqgmW9VgGsfrxX90nOXel6BAV7x1vTe4L1v+6tyNmJDR1kHc1yC7D+I=
Message-ID: <a4e6962a05050108412c50e9b5@mail.gmail.com>
Date: Sun, 1 May 2005 10:41:30 -0500
From: Eric Van Hensbergen <ericvh@gmail.com>
Reply-To: Eric Van Hensbergen <ericvh@gmail.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Subject: Re: [PATCH] private mounts
Cc: jamie@shareable.org, hch@infradead.org, bulb@ucw.cz,
       viro@parcelfarce.linux.theplanet.co.uk, linux-fsdevel@vger.kernel.org,
       linux-kernel@vger.kernel.org, akpm@osdl.org
In-Reply-To: <E1DS7RB-0004Md-00@dorka.pomaz.szeredi.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Content-Disposition: inline
References: <20050425071047.GA13975@vagabond>
	 <E1DRoDm-0002G9-00@dorka.pomaz.szeredi.hu>
	 <20050430094218.GA32679@mail.shareable.org>
	 <E1DRoz9-0002JL-00@dorka.pomaz.szeredi.hu>
	 <20050430143609.GA4362@mail.shareable.org>
	 <E1DRuNU-0002el-00@dorka.pomaz.szeredi.hu>
	 <20050430164258.GA6498@mail.shareable.org>
	 <E1DRvRc-0002lq-00@dorka.pomaz.szeredi.hu>
	 <20050430235453.GA11494@mail.shareable.org>
	 <E1DS7RB-0004Md-00@dorka.pomaz.szeredi.hu>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On 5/1/05, Miklos Szeredi <miklos@szeredi.hu> wrote:
> 
> As someone pointed out, CAP_SYS_ADMIN processes can already escape the
> chroot jail with CLONE_NEWNS.  (fd=open("."); clone(CLONE_NEWNS);
> [child:] fchdir(fd); chdir(".."))
> 

This really does seem like a bug.  Is there are a reason behind this
"feature", or should one of us be looking into a patch to correct
this?

Miklos you earlier suggested:
>>>How about fixing fchdir, so it checks whether you gone outside the
>>>tree under current->fs->rootmnt?  Should be fairly easy to do.

         -eric

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261938AbVEKJFT@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261938AbVEKJFT (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 11 May 2005 05:05:19 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261935AbVEKJB5
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 11 May 2005 05:01:57 -0400
Received: from pentafluge.infradead.org ([213.146.154.40]:65450 "EHLO
	pentafluge.infradead.org") by vger.kernel.org with ESMTP
	id S261938AbVEKJAL (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 11 May 2005 05:00:11 -0400
Date: Wed, 11 May 2005 10:00:02 +0100
From: Christoph Hellwig <hch@infradead.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: hch@infradead.org, bulb@ucw.cz, viro@parcelfarce.linux.theplanet.co.uk,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
Subject: Re: [PATCH] private mounts
Message-ID: <20050511090002.GC24841@infradead.org>
Mail-Followup-To: Christoph Hellwig <hch@infradead.org>,
	Miklos Szeredi <miklos@szeredi.hu>, bulb@ucw.cz,
	viro@parcelfarce.linux.theplanet.co.uk,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	akpm@osdl.org
References: <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk> <E1DPoCg-0000W0-00@localhost> <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk> <E1DPoRz-0000Y0-00@localhost> <20050424211942.GN13052@parcelfarce.linux.theplanet.co.uk> <E1DPofK-0000Yu-00@localhost> <20050425071047.GA13975@vagabond> <E1DQ0Mc-0007B5-00@dorka.pomaz.szeredi.hu> <20050430083516.GC23253@infradead.org> <E1DRoDm-0002G9-00@dorka.pomaz.szeredi.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E1DRoDm-0002G9-00@dorka.pomaz.szeredi.hu>
User-Agent: Mutt/1.4.1i
X-SRS-Rewrite: SMTP reverse-path rewritten from <hch@infradead.org> by pentafluge.infradead.org
	See http://www.infradead.org/rpr.html
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Sat, Apr 30, 2005 at 11:25:10AM +0200, Miklos Szeredi wrote:
> > > > I can't write a script that reads your mind. But I sure can write
> > > > a script that finds out what you mounted in the other shells (with help
> > > > of a little wrapper around the mount command).
> > > 
> > > How do you bind mount it from a different namespace?  You _do_ need
> > > bind mount, since a new mount might require password input, etc...
> > 
> > Not nessecarily.  The filesystem gets called into ->get_sb for every mount,
> > and can then decided whether to return an existing superblock instance or
> > setup a new one.  If the credentials for the new mount match an old one
> > it can just reuse it.  (e.g. for block based filesystem it will always reuse
> > right now)
> 
> And if the credentials are checked in userspace (sshfs)?

The it needs to call to userspace in ->get_sb..

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261156AbVEKKn1@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261156AbVEKKn1 (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 11 May 2005 06:43:27 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261204AbVEKKn1
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 11 May 2005 06:43:27 -0400
Received: from rev.193.226.232.93.euroweb.hu ([193.226.232.93]:63250 "EHLO
	dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP
	id S261156AbVEKKnV (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 11 May 2005 06:43:21 -0400
To: hch@infradead.org
CC: bulb@ucw.cz, viro@parcelfarce.linux.theplanet.co.uk,
       linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       akpm@osdl.org
In-reply-to: <20050511090002.GC24841@infradead.org> (message from Christoph
	Hellwig on Wed, 11 May 2005 10:00:02 +0100)
Subject: Re: [PATCH] private mounts
References: <20050424205422.GK13052@parcelfarce.linux.theplanet.co.uk> <E1DPoCg-0000W0-00@localhost> <20050424210616.GM13052@parcelfarce.linux.theplanet.co.uk> <E1DPoRz-0000Y0-00@localhost> <20050424211942.GN13052@parcelfarce.linux.theplanet.co.uk> <E1DPofK-0000Yu-00@localhost> <20050425071047.GA13975@vagabond> <E1DQ0Mc-0007B5-00@dorka.pomaz.szeredi.hu> <20050430083516.GC23253@infradead.org> <E1DRoDm-0002G9-00@dorka.pomaz.szeredi.hu> <20050511090002.GC24841@infradead.org>
Message-Id: <E1DVofz-0001dC-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Wed, 11 May 2005 12:42:51 +0200
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

> > > > > I can't write a script that reads your mind. But I sure can
> > > > > write a script that finds out what you mounted in the other
> > > > > shells (with help of a little wrapper around the mount
> > > > > command).
> > > > 
> > > > How do you bind mount it from a different namespace?  You _do_
> > > > need bind mount, since a new mount might require password
> > > > input, etc...
> > > 
> > > Not nessecarily.  The filesystem gets called into ->get_sb for
> > > every mount, and can then decided whether to return an existing
> > > superblock instance or setup a new one.  If the credentials for
> > > the new mount match an old one it can just reuse it.  (e.g. for
> > > block based filesystem it will always reuse right now)
> > 
> > And if the credentials are checked in userspace (sshfs)?
> 
> The it needs to call to userspace in ->get_sb..

That's clear.

What I don't get is what's the point in adding complexity to the
kernel and userspace programs, when it can be done without _any_
changes, just by doing a bind mount.

It's not just calling ->get_sb.  It's finding the right filesystem
daemon, that has been started with the exact same command line
arguments, environment etc.

It's just not practical.

Miklos

