[RFC][2.6 patch] Allow creation of new namespaces during mount system call

[RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Eric Van Hensbergen]

The motivation behind this patch is to make private namespaces more
accessible by allowing their creation at mount/bind time.

Based on some of the FUSE permissions discussions, I wanted to check
into modifying the mount system calls -- adding a flag which created a
new namespace for the resulting mount.  I quickly discovered that what
I typically wanted (for the case of running a mount command) was to
actually create a new namespace for the parent thread (typically the
shell), inherit that namespace, and then perform the mount.

Its not clear to me that both options are needed, cloning the parent's
namespace seems to be what you want most of the time.

In order to minimize code impact I split the copy_namespace function,
perhaps the right long term solution is to change it's interface to
accommodate the changes.  Things look a bit more invasive as I moved
the copy_namespace function above do_mount.  The patch follows:

  fs/namespace.c     |  193
+++++++++++++++++++++++++++++------------------------
  include/linux/fs.h |    2 
 2 files changed, 108 insertions(+), 87 deletions(-)

--- linux-2.5/include/linux/fs.h	2005-04-19 17:02:28.530152496 -0500
+++ newns-2.5/include/linux/fs.h	2005-04-19 17:03:52.619368992 -0500
@@ -103,6 +103,8 @@ extern int dir_notify_enable;
 #define MS_REC		16384
 #define MS_VERBOSE	32768
  #define MS_POSIXACL	(1<<16)	/* VFS does not apply the umask */
+#define MS_CLONE_NEWNS	(1<<17) /* clone my namespace before mount */
+#define MS_CLONE_NEWPNS (1<<18) /* clone my & my parent namespace */
 #define MS_ACTIVE	(1<<30)
 #define MS_NOUSER	(1<<31)
 
--- linux-2.5/fs/namespace.c	2005-04-19 17:02:14.551277608 -0500
+++ newns-2.5/fs/namespace.c	2005-04-19 17:03:38.227556880 -0500
@@ -991,6 +991,104 @@ int copy_mount_options(const void __user
 	return 0;
 }
 
+int update_namespace(struct task_struct *tsk, struct namespace *new_ns )
+{
+	struct namespace *namespace = tsk->namespace;
+	struct vfsmount *rootmnt = NULL, *pwdmnt = NULL, *altrootmnt = NULL;
+	struct fs_struct *fs = tsk->fs;
+	struct vfsmount *p, *q;
+
+	if (!namespace)
+		return 0;
+
+	get_namespace(namespace);
+
+	if (!capable(CAP_SYS_ADMIN)) {
+		put_namespace(namespace);
+		return -EPERM;
+	}
+
+	down_write(&tsk->namespace->sem);
+	if(!new_ns) {
+		new_ns = kmalloc(sizeof(struct namespace), GFP_KERNEL);
+		if (!new_ns)
+			goto out;
+
+		atomic_set(&new_ns->count, 1);
+		init_rwsem(&new_ns->sem);
+		INIT_LIST_HEAD(&new_ns->list);
+
+		/* First pass: copy the tree topology */
+		new_ns->root = copy_tree(namespace->root, namespace->root->mnt_root);
+		if (!new_ns->root) {
+			up_write(&tsk->namespace->sem);
+			kfree(new_ns);
+			goto out;
+		}
+		spin_lock(&vfsmount_lock);
+		list_add_tail(&new_ns->list, &new_ns->root->mnt_list);
+		spin_unlock(&vfsmount_lock);
+	} else 
+		get_namespace(new_ns);
+
+	/*
+	 * Second pass: switch the tsk->fs->* elements and mark new vfsmounts
+	 * as belonging to new namespace.  We have already acquired a private
+	 * fs_struct, so tsk->fs->lock is not needed.
+	 */
+	p = namespace->root;
+	q = new_ns->root;
+	while (p) {
+		q->mnt_namespace = new_ns;
+		if (fs) {
+			if (p == fs->rootmnt) {
+				rootmnt = p;
+				fs->rootmnt = mntget(q);
+			}
+			if (p == fs->pwdmnt) {
+				pwdmnt = p;
+				fs->pwdmnt = mntget(q);
+			}
+			if (p == fs->altrootmnt) {
+				altrootmnt = p;
+				fs->altrootmnt = mntget(q);
+			}
+		}
+		p = next_mnt(p, namespace->root);
+		q = next_mnt(q, new_ns->root);
+	}
+	up_write(&tsk->namespace->sem);
+
+	tsk->namespace = new_ns;
+
+	if (rootmnt)
+		mntput(rootmnt);
+	if (pwdmnt)
+		mntput(pwdmnt);
+	if (altrootmnt)
+		mntput(altrootmnt);
+
+	put_namespace(namespace);
+	return 0;
+
+out:
+	put_namespace(namespace);
+	return -ENOMEM;
+}
+
+int copy_namespace(int flags, struct task_struct *tsk)
+{
+	if (!tsk->namespace)
+		return 0;
+
+	if (!(flags & CLONE_NEWNS)) {
+		get_namespace(tsk->namespace);
+		return 0;
+	}
+
+	return update_namespace( tsk, NULL );
+}
+
 /*
  * Flags is a 32-bit value that allows up to 31 non-fs dependent flags to
  * be given to the mount() call (ie: read-only, no-dev, no-suid etc).
@@ -1033,7 +1131,14 @@ 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_CLONE_NEWNS)
+		copy_namespace( CLONE_NEWNS, current);
+	if (flags & MS_CLONE_NEWPNS) {
+		copy_namespace( CLONE_NEWNS, current->real_parent);
+		update_namespace( current, current->real_parent->namespace);
+	}
+
+	flags &= ~(MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_ACTIVE|MS_CLONE_NEWNS|MS_CLONE_NEWPNS);
 
 	/* ... and get the mountpoint */
 	retval = path_lookup(dir_name, LOOKUP_FOLLOW, &nd);
@@ -1059,92 +1164,6 @@ dput_out:
 	return retval;
 }
 
-int copy_namespace(int flags, struct task_struct *tsk)
-{
-	struct namespace *namespace = tsk->namespace;
-	struct namespace *new_ns;
-	struct vfsmount *rootmnt = NULL, *pwdmnt = NULL, *altrootmnt = NULL;
-	struct fs_struct *fs = tsk->fs;
-	struct vfsmount *p, *q;
-
-	if (!namespace)
-		return 0;
-
-	get_namespace(namespace);
-
-	if (!(flags & CLONE_NEWNS))
-		return 0;
-
-	if (!capable(CAP_SYS_ADMIN)) {
-		put_namespace(namespace);
-		return -EPERM;
-	}
-
-	new_ns = kmalloc(sizeof(struct namespace), GFP_KERNEL);
-	if (!new_ns)
-		goto out;
-
-	atomic_set(&new_ns->count, 1);
-	init_rwsem(&new_ns->sem);
-	INIT_LIST_HEAD(&new_ns->list);
-
-	down_write(&tsk->namespace->sem);
-	/* First pass: copy the tree topology */
-	new_ns->root = copy_tree(namespace->root, namespace->root->mnt_root);
-	if (!new_ns->root) {
-		up_write(&tsk->namespace->sem);
-		kfree(new_ns);
-		goto out;
-	}
-	spin_lock(&vfsmount_lock);
-	list_add_tail(&new_ns->list, &new_ns->root->mnt_list);
-	spin_unlock(&vfsmount_lock);
-
-	/*
-	 * Second pass: switch the tsk->fs->* elements and mark new vfsmounts
-	 * as belonging to new namespace.  We have already acquired a private
-	 * fs_struct, so tsk->fs->lock is not needed.
-	 */
-	p = namespace->root;
-	q = new_ns->root;
-	while (p) {
-		q->mnt_namespace = new_ns;
-		if (fs) {
-			if (p == fs->rootmnt) {
-				rootmnt = p;
-				fs->rootmnt = mntget(q);
-			}
-			if (p == fs->pwdmnt) {
-				pwdmnt = p;
-				fs->pwdmnt = mntget(q);
-			}
-			if (p == fs->altrootmnt) {
-				altrootmnt = p;
-				fs->altrootmnt = mntget(q);
-			}
-		}
-		p = next_mnt(p, namespace->root);
-		q = next_mnt(q, new_ns->root);
-	}
-	up_write(&tsk->namespace->sem);
-
-	tsk->namespace = new_ns;
-
-	if (rootmnt)
-		mntput(rootmnt);
-	if (pwdmnt)
-		mntput(pwdmnt);
-	if (altrootmnt)
-		mntput(altrootmnt);
-
-	put_namespace(namespace);
-	return 0;
-
-out:
-	put_namespace(namespace);
-	return -ENOMEM;
-}
-
 asmlinkage long sys_mount(char __user * dev_name, char __user * dir_name,
 			  char __user * type, unsigned long flags,
 			  void __user * data)

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Al Viro]

On Tue, Apr 19, 2005 at 05:13:32PM -0500, Eric Van Hensbergen wrote:
> The motivation behind this patch is to make private namespaces more
> accessible by allowing their creation at mount/bind time.
> 
> Based on some of the FUSE permissions discussions, I wanted to check
> into modifying the mount system calls -- adding a flag which created a
> new namespace for the resulting mount.  I quickly discovered that what
> I typically wanted (for the case of running a mount command) was to
> actually create a new namespace for the parent thread (typically the
> shell), inherit that namespace, and then perform the mount.
> 
> Its not clear to me that both options are needed, cloning the parent's
> namespace seems to be what you want most of the time.
> 
> In order to minimize code impact I split the copy_namespace function,
> perhaps the right long term solution is to change it's interface to
> accommodate the changes.  Things look a bit more invasive as I moved
> the copy_namespace function above do_mount.  The patch follows:

*UGH*

So what happens to those who happen to share task->fs with the parent?

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Eric Van Hensbergen]

On 4/19/05, Al Viro <viro@parcelfarce.linux.theplanet.co.uk> wrote:
> On Tue, Apr 19, 2005 at 05:13:32PM -0500, Eric Van Hensbergen wrote:
> > The motivation behind this patch is to make private namespaces more
> > accessible by allowing their creation at mount/bind time.
> >
> 
> *UGH*
> 
> So what happens to those who happen to share task->fs with the parent?
> 

Okay, I'll admit to being a bit too hasty with pushing out that patch
- I was being particularly myopic looking for a solution only for a
command-line mount.  Are you generally opposed to new namespace
creation at mount time or just my slimy hack?  A shared task->fs seems
like something which could be easily checked against and disallowed.

       -eric

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Al Viro]

On Tue, Apr 19, 2005 at 06:53:29PM -0500, Eric Van Hensbergen wrote:
> On 4/19/05, Al Viro <viro@parcelfarce.linux.theplanet.co.uk> wrote:
> > On Tue, Apr 19, 2005 at 05:13:32PM -0500, Eric Van Hensbergen wrote:
> > > The motivation behind this patch is to make private namespaces more
> > > accessible by allowing their creation at mount/bind time.
> > >
> > 
> > *UGH*
> > 
> > So what happens to those who happen to share task->fs with the parent?
> > 
> 
> Okay, I'll admit to being a bit too hasty with pushing out that patch
> - I was being particularly myopic looking for a solution only for a
> command-line mount.  Are you generally opposed to new namespace
> creation at mount time or just my slimy hack?  A shared task->fs seems
> like something which could be easily checked against and disallowed.

a) ability to create a private namespace without forking anything - sure,
that would be useful.  However, that's not something I would push into
mount(2) (already overloaded to hell and back).

There used to be a kinda-sorta agreement on a new syscall:
	unshare(bitmap)
with arguments like those of clone(2).  That's not just for namespaces -
e.g. you might legitimately want to unshare VM in a thread and leave the
rest alone.  Or unshare ->fs (i.e. uncouple cwd from the rest of group).

Most of the code is already there - do_fork() has to do such stuff anyway.
So how about adding sys_unshare(flags) that would do that job?  Flags would
correspond to those of clone(2), except that all these guys would be
"what do we unshare" instead of "what do we leave shared".


b) I _really_ don't like the idea of messing with the parent.  Make it
a shell builtin if you want to affect shell behaviour; the same reason
why cd is a builtin and not an external command.


c) I would be really, really careful with implications of "let user
do whatever he wants" - that certainly should include bindings and
that can create heaps of fun for suid stuff.  More comments when
I get around to digging through FUSE thread...

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Jamie Lokier]

Al Viro wrote:
> Most of the code is already there - do_fork() has to do such stuff anyway.
> So how about adding sys_unshare(flags) that would do that job?  Flags would
> correspond to those of clone(2), except that all these guys would be
> "what do we unshare" instead of "what do we leave shared".

That would let a program split off into its own namespace, but that's
not really what's needed for FUSE.

For FUSE, what's needed is that a user can mount something, and the
mounted fs is visible only to that user, but it's visible to _all_ of
the user's processes.

For example, as a non-root user I should be able to mount an "ftpfs"
or "sshfs" on /home/jamie/mnt/remote in one shell window, and be able
to cd inside that directory from a different shell window.  But other
users, including root, should not be able to see the mounted content
of that directory.  (The mounted fs is really just an interface to a
program owned by me - a program running ftp or ssh in this case).

We think namespaces are a nice way to do that: making a user-owned
filesystem only visible to a user.  But the mechanism of CLONE_NEWNS
does not work, because it presumes namespace divisions are only
propagated over parent-child divisions, like environment variables.

What we really want is a mount point that propagates across all the
processes owned by one user, but is not there for other users.

The shared subtree mechanism seems like it has the basic ideas for this.

> b) I _really_ don't like the idea of messing with the parent.  Make it
> a shell builtin if you want to affect shell behaviour; the same reason
> why cd is a builtin and not an external command.

I agree.  That's just a poor hack to let a "usermount" program alter
the namespace of the shell it's called from.  It won't work in general.

> c) I would be really, really careful with implications of "let user
> do whatever he wants" - that certainly should include bindings and
> that can create heaps of fun for suid stuff.  More comments when
> I get around to digging through FUSE thread...

Probably the best thing to do for suid programs is this:

   - Have a namespace per user.  The user's namespace will be entered
     by the "login" program somehow.

   - All logins to the same user acquire the same per-user namespace.
     This isn't possible at the moment; it would be a kernel extension
     + administrative change to login.

   - Mounts done by the user are private to the per-user namespace.

   - Mounts done by the user are still restricted to directories writable
     by the user, so he cannot modify /etc or /usr - your /etc/shadow
     attack is not possible.

   - suid programs run by the user inherit the same per-user namespace.
     In other words, the per-user namespace is entered at login time
     (by the login program doing a syscall), not when changing uid.
     In this way, a user can pass a private pathname to an suid
     program, and the suid program will be able to operate on that
     file properly.

-- Jamie

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Al Viro]

On Wed, Apr 20, 2005 at 10:45:58AM +0100, Jamie Lokier wrote:
> For FUSE, what's needed is that a user can mount something, and the
> mounted fs is visible only to that user, but it's visible to _all_ of
> the user's processes.

So get that namespace as soon as you log in.
 
> We think namespaces are a nice way to do that: making a user-owned
> filesystem only visible to a user.  But the mechanism of CLONE_NEWNS
> does not work, because it presumes namespace divisions are only
> propagated over parent-child divisions, like environment variables.
 
> What we really want is a mount point that propagates across all the
> processes owned by one user, but is not there for other users.

This is almost certainly bogus.  Same user can easily want several
different environments set on the same box.

>    - Have a namespace per user.  The user's namespace will be entered
>      by the "login" program somehow.

Trivial right now - just have libpam do that.
 
>    - All logins to the same user acquire the same per-user namespace.
>      This isn't possible at the moment; it would be a kernel extension
>      + administrative change to login.

No.  Identical setup at login time - sure.  Enforced _single_ namespace
is just plain wrong.  Moreover, "all user's processes" is the wrong answer
to practically any question (well, aside of "what processes do you kill
when you get rid of luser's account").

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Jamie Lokier]

Al Viro wrote:
> On Wed, Apr 20, 2005 at 10:45:58AM +0100, Jamie Lokier wrote:
> > For FUSE, what's needed is that a user can mount something, and the
> > mounted fs is visible only to that user, but it's visible to _all_ of
> > the user's processes.
> 
> So get that namespace as soon as you log in.

Yes.  How?

It is usual to log in on multiple terminals.  You'd _usually_ want
virtual filesystems mounted in one terminal to be visisble in others.

Hmm.  A fairly radical change to the login process would be able to do
it: have login pass the terminal file descriptor to a per-user process
which spawns user login shells from a common namespace.

That would work with the current CLONE_NEWNS mechanism :)

It's quite a radical change to the way logins are done, though.

> > We think namespaces are a nice way to do that: making a user-owned
> > filesystem only visible to a user.  But the mechanism of CLONE_NEWNS
> > does not work, because it presumes namespace divisions are only
> > propagated over parent-child divisions, like environment variables.
>  
> > What we really want is a mount point that propagates across all the
> > processes owned by one user, but is not there for other users.
> 
> This is almost certainly bogus.  Same user can easily want several
> different environments set on the same box.

I agree, but didn't say that before as the explanation is complicated
enough.

It shouldn't be literally per-user - it should be possible for a user
to have several environment _when_ they want that.  chroot-jail style
virtual server environments require that too.

But that shouldn't be the only option - because it would be horrible
to use.  If I login on multiple terminals, I normally want to mount
filesystems in /home/jamie/mnt on one terminal, and use them on another.

> >    - Have a namespace per user.  The user's namespace will be entered
> >      by the "login" program somehow.
> 
> Trivial right now - just have libpam do that.

How can libpam join the user's existing namespace?

Having a separate usermount-namespace for each login of the same user
would not be nice to use.

> >    - All logins to the same user acquire the same per-user namespace.
> >      This isn't possible at the moment; it would be a kernel extension
> >      + administrative change to login.
> 
> No.  Identical setup at login time - sure.  Enforced _single_ namespace
> is just plain wrong.  Moreover, "all user's processes" is the wrong answer
> to practically any question (well, aside of "what processes do you kill
> when you get rid of luser's account").

I agree.  Certainly the kernel should not be looking at uid for this.
The actual determination of which processes share mounts should be
determined entirely by userspace.

But right now, the kernel doesn't provide a mechanism (that I know of)
whereby a new login shell can use the namespace of an existing process
- something that would be desirable if it were possible.

The idea I gave at the start of this mail - a daemon per user spawning
login shells using a shared namespace - would work using the available
CLONE_NEWNS mechanism.  But it doesn't fit very well with libpam, nor
with the usual tree relationship of parent-child processes when using
"su" and such.

-- Jamie

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Al Viro]

On Wed, Apr 20, 2005 at 01:03:40PM +0100, Jamie Lokier wrote:
> It shouldn't be literally per-user - it should be possible for a user
> to have several environment _when_ they want that.  chroot-jail style
> virtual server environments require that too.
> 
> But that shouldn't be the only option - because it would be horrible
> to use.  If I login on multiple terminals, I normally want to mount
> filesystems in /home/jamie/mnt on one terminal, and use them on another.

And when you log in on several terminals you usually want same $PATH.
You don't do that by sharing VM between shell processes, do you?  Sure,
that would work with sufficient kernel-side hacks for joining thread
group and making e.g. bash multithreaded.  Nobody does it though - it
doesn't buy you anything really useful.
 
> How can libpam join the user's existing namespace?
> 
> Having a separate usermount-namespace for each login of the same user
> would not be nice to use.

I don't see why.  _IF_ you can change the set of mounts after you log in,
there's no more need to do any kernel tricks for that stuff than you would
need for environment, etc.  If you can't - well, the last point where you
can get something set up is login with no changes afterwards.  In that case
everything is just as trivial...

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Ram]

On Wed, 2005-04-20 at 05:39, Al Viro wrote:
> On Wed, Apr 20, 2005 at 01:03:40PM +0100, Jamie Lokier wrote:
> > It shouldn't be literally per-user - it should be possible for a user
> > to have several environment _when_ they want that.  chroot-jail style
> > virtual server environments require that too.
> > 
> > But that shouldn't be the only option - because it would be horrible
> > to use.  If I login on multiple terminals, I normally want to mount
> > filesystems in /home/jamie/mnt on one terminal, and use them on another.
> 
> And when you log in on several terminals you usually want same $PATH.
> You don't do that by sharing VM between shell processes, do you?  Sure,
> that would work with sufficient kernel-side hacks for joining thread
> group and making e.g. bash multithreaded.  Nobody does it though - it
> doesn't buy you anything really useful.
>  
> > How can libpam join the user's existing namespace?
> > 
> > Having a separate usermount-namespace for each login of the same user
> > would not be nice to use.
> 
> I don't see why.  _IF_ you can change the set of mounts after you log in,
> there's no more need to do any kernel tricks for that stuff than you would
> need for environment, etc.  If you can't - well, the last point where you
> can get something set up is login with no changes afterwards.  In that case
> everything is just as trivial...
> -

Reading through the thread I assume the requirement is:

1) A User being able to create his own VFS-mount environment 
2) being able to use the same VFS-mount environment from 
    multiple login sessions.
3) Being able to switch some processes to some other
      VFS-mount environment.

How about making namespace's as first class objects with some associated
name or device in the device tree having owner/permissions etc.  any
process which forks off a namespace shall create the
device node for the namespace. If some other process wants to use
the same namespace, it can do so by attaching itself to the namespace
dynamically? Offcourse children processes inherit the same namespace.


If such a functionality existed, then a user can create his own
namespace if one does not exist, and if one exist he can attach to
that namespace?  Not thought through this idea entirely, but seems
to provide the desired functionality.

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

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Al Viro]

On Wed, Apr 20, 2005 at 09:51:26AM -0700, Ram wrote:
> Reading through the thread I assume the requirement is:
> 
> 1) A User being able to create his own VFS-mount environment 
> 2) being able to use the same VFS-mount environment from 
>     multiple login sessions.
> 3) Being able to switch some processes to some other
>       VFS-mount environment.

Excuse me, but could somebody give coherent rationale for such requirements?
_Especially_ for joining existing group by completely unrelated process -
something we don't do for any other component of process.

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Miklos Szeredi]

> > Reading through the thread I assume the requirement is:
> > 
> > 1) A User being able to create his own VFS-mount environment 
> > 2) being able to use the same VFS-mount environment from 
> >     multiple login sessions.
> > 3) Being able to switch some processes to some other
> >       VFS-mount environment.
> 
> Excuse me, but could somebody give coherent rationale for such requirements?
> _Especially_ for joining existing group by completely unrelated process -
> something we don't do for any other component of process.

The user expects to have the see the same files in all sessions,
whether those be local logins, remote logins, ftp/scp/etc sessions.

If I'm remotely logged into server X from Y, and want to use scp to
copy some file from X to Y or vica versa, I will want my private
mounts to be visible from the scp.

A single global namespace makes perfect sense here.  Why do people
want private namespaces?  The usual reason given is that the global
namespace should not be "polluted" with private mounts.  Is that a
good reason?  I'm not sure.

Miklos

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Eric Van Hensbergen]

On 4/20/05, Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> The user expects to have the see the same files in all sessions,
> whether those be local logins, remote logins, ftp/scp/etc sessions.
>
>
> A single global namespace makes perfect sense here.  Why do people
> want private namespaces?
>

I disagree with this, I think there are plenty of situations where I
may want to have several different namespaces for several different
sessions.  Once you unlock namespace manipulation for users, all sorts
of new models of how to interact with the system fall out of that
capability.

Not to mention the fact that if you accidentally screw up your private
name space, fixing it is as easy as exiting that shell (or closing
that window, etc.)  Could you imagine if your PATH environment
variable was shared between all your shells and logins?  A simple typo
when extending your PATH in a single shell would screw all your
sessions.

                  -eric

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Miklos Szeredi]

(Please don't post separately to different recipients, that makes
replying quite awkward.  Always reply to all, it's the Right Thing)

> I disagree with this, I think there are plenty of situations where I
> may want to have several different namespaces for several different
> sessions.  Once you unlock namespace manipulation for users, all sorts
> of new models of how to interact with the system fall out of that
> capability.

I agree fully with you.

What I was getting at, is why people want to use private namespaces in
a way that contradits the "privateness" of the namespace: i.e. share
it between sessions etc.  Global namespace makes sense in that case.

Miklos

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Jamie Lokier]

Miklos Szeredi wrote:
> (Please don't post separately to different recipients, that makes
> replying quite awkward.  Always reply to all, it's the Right Thing)
> 
> > I disagree with this, I think there are plenty of situations where I
> > may want to have several different namespaces for several different
> > sessions.  Once you unlock namespace manipulation for users, all sorts
> > of new models of how to interact with the system fall out of that
> > capability.
> 
> I agree fully with you.
> 
> What I was getting at, is why people want to use private namespaces in
> a way that contradits the "privateness" of the namespace: i.e. share
> it between sessions etc.  Global namespace makes sense in that case.

The problem with global namespace is they're seen by everyone.

There's an administrative need for things which are not visible by
other users, but still shared between sessions.

Al Viro is right to point out that environment variables are not
shared.  But he forgets that _files_ are shared.  Privately mounted
filesystems for the purpose of defining a "namespace session" - well,
the question is whether they should behave more like files or more
like environment variables.

-- Jamie

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Al Viro]

On Wed, Apr 20, 2005 at 09:43:47PM +0100, Jamie Lokier wrote:
> Al Viro is right to point out that environment variables are not
> shared.  But he forgets that _files_ are shared.

So they are.  ~/.profile, for instance ;-)

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Jamie Lokier]

Al Viro wrote:
> On Wed, Apr 20, 2005 at 09:43:47PM +0100, Jamie Lokier wrote:
> > Al Viro is right to point out that environment variables are not
> > shared.  But he forgets that _files_ are shared.
> 
> So they are.  ~/.profile, for instance ;-)

And ~/.cvspass.  Mysteriously, when I add something to .cvspass using
"cvs login", I then have the same access in all my login windows... ;)

Yes it's a bit muddled.

-- Jamie

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Al Viro]

On Wed, Apr 20, 2005 at 07:53:04PM +0200, Miklos Szeredi wrote:
> The user expects to have the see the same files in all sessions,
> whether those be local logins, remote logins, ftp/scp/etc sessions.

Umm...  You know, I would be *very* unhappy if I found that some process
on parcelfarce was able to see the contents of ~/.ssh/* from the laptop
I'm using right now.  Even more so if that would apply to random ftp
sewer I happen to use at the moment...
 
> If I'm remotely logged into server X from Y, and want to use scp to
> copy some file from X to Y or vica versa, I will want my private
> mounts to be visible from the scp.

Do you?  Really?  OK, so I've got ~/bin/ and ~/bin/arch/ in my path on
my boxen.  The latter has ~/bin/{i386,alpha,sparc,amd64,hppa,ppc} bound
on it - depending on the host I'm using.  Tell me, why would I want that
private mount to be visible when I log in from one box to another?  To
make sure that wrong binaries would be picked?

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Jamie Lokier]

Al Viro wrote:
> > If I'm remotely logged into server X from Y, and want to use scp to
> > copy some file from X to Y or vica versa, I will want my private
> > mounts to be visible from the scp.
> 
> Do you?  Really?  OK, so I've got ~/bin/ and ~/bin/arch/ in my path on
> my boxen.  The latter has ~/bin/{i386,alpha,sparc,amd64,hppa,ppc} bound
> on it - depending on the host I'm using.  Tell me, why would I want that
> private mount to be visible when I log in from one box to another?  To
> make sure that wrong binaries would be picked?

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.

-- Jamie

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Eric Van Hensbergen]

On 4/20/05, Al Viro <viro@parcelfarce.linux.theplanet.co.uk> wrote:
> 
> Excuse me, but could somebody give coherent rationale for such requirements?
> _Especially_ for joining existing group by completely unrelated process -
> something we don't do for any other component of process.
> 
> On Wed, Apr 20, 2005 at 09:51:26AM -0700, Ram wrote:
> > Reading through the thread I assume the requirement is:
> >
> > 1) A User being able to create his own VFS-mount environment
> >

I think this enables a more secure environment for users when they
mount/bind their own file systems (be it network or synthetic).   It
helps prevent them from "spoofing" files and/or resources for users
other than themselves.  Security exposure for "system" files can be
limited by preventing users from mounting/binding over secure
locations and by enforcing nosuid/nosgid on user mounted file systems.
 Since there is no way to get at the "private" namespace, its contents
are "safe" from otherwise privileged users of the system (I'm not sure
if I agree with this, but I think that is part of what sent us down
this thread in the first place).

> > 2) being able to use the same VFS-mount environment from
> >     multiple login sessions.
> > 3) Being able to switch some processes to some other
> >       VFS-mount environment.

These requirements are less clear to me - although it might be useful
to structure things in such a way that it is easy to recreate a
VFS-mount environment.  To a certain extent the information in
/proc/x/mounts gives this information, but I'm unclear on how this
might impact synthetic file systems.

Another alternative is to allow easy re-export of a constructed
VFS-mount environment so that it could be mounted/bound into other
environments.  The Plan 9 /srv (3) device kind of works this way.  I
assume that is some of the intent under the shared subtree stuff as
well.

Of course that doesn't answer the question of why you need to do these
things in the first place.  One case is when you've opened up a remote
file system in one window under a private namespace and realize you
need access to those files in another window -- opening up a new
connection to the server from the other window seems somewhat heavy
weight -- I imagine the same thing would be the case in a synthetic
file system case (like a user-space encrypted file system).

In Plan 9, the connection to the server (whether remote or local
synthetic) would be represented by a handle in the /srv device.  This
single instance can then be mounted onto a particular process'
namespace, and all that is required to share the instance is the /srv
handle.  The /srv handles can be per-user or just protected with
normal file system permissions (I guess this is sorta similar to Ram's
device suggestion).

All in all, I think these last two requirements represent a much
tougher problem and there very well may be a better solution to what
they are trying to do.  Its also worth noting (as I think someone did)
that this invalidates private namespace's prevention of unauthorized
"super-user" access to user files (which is somewhat bogus anyways).

      -eric

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Ram]

On Wed, 2005-04-20 at 10:09, Al Viro wrote:
> On Wed, Apr 20, 2005 at 09:51:26AM -0700, Ram wrote:
> > Reading through the thread I assume the requirement is:
> > 
> > 1) A User being able to create his own VFS-mount environment 
> > 2) being able to use the same VFS-mount environment from 
> >     multiple login sessions.
> > 3) Being able to switch some processes to some other
> >       VFS-mount environment.
> 
> Excuse me, but could somebody give coherent rationale for such requirements?
> _Especially_ for joining existing group by completely unrelated process -
> something we don't do for any other component of process.

Would it be wrong to do (3) if access-controlled properly? Currently the
only way to share the same namespace is to inherit it, which is possible
only if the process belongs to the heridity chain of the creator of the
namespace.

I extracted the requirement (3) from this discussion 
--------------------------------------------------------------------
> We think namespaces are a nice way to do that: making a user-owned
> filesystem only visible to a user.  But the mechanism of CLONE_NEWNS
> does not work, because it presumes namespace divisions are only
> propagated over parent-child divisions, like environment variables.
 
> What we really want is a mount point that propagates across all the
> processes owned by one user, but is not there for other users.

This is almost certainly bogus.  Same user can easily want several
different environments set on the same box.
--------------------------------------------------------------------

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

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Jamie Lokier]

Ram wrote:
> > What we really want is a mount point that propagates across all the
> > processes owned by one user, but is not there for other users.
> 
> This is almost certainly bogus.  Same user can easily want several
> different environments set on the same box.

Yes of course.

The problem is the current mechanism _forces_ the user to have
different environments on the same box - there's no choice.

Which is, as Al says, just like environment variables.

But not like files - if I create a file called $HOME/foo, I expect
that I can access it from a different login.  I might want to have
different environments, but that's not the _default_ when dealing with
files.

The question is whether private user-mounts should, by default, behave
more like environment variables or more like files.

-- Jamie

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Christoph Hellwig]

On Wed, Apr 20, 2005 at 11:04:29PM +0100, Jamie Lokier wrote:
> The problem is the current mechanism _forces_ the user to have
> different environments on the same box - there's no choice.
> 
> Which is, as Al says, just like environment variables.
> 
> But not like files - if I create a file called $HOME/foo, I expect
> that I can access it from a different login.  I might want to have
> different environments, but that's not the _default_ when dealing with
> files.
> 
> The question is whether private user-mounts should, by default, behave
> more like environment variables or more like files.

I think you're a little confused. Files are a global ressource and as
such it makes sense to see them everywhere.  But you're not arguing for
making the namespace a global ressource (again), but a per-user one,
which has no precedence.

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Jamie Lokier]

Christoph Hellwig wrote:
> > The problem is the current mechanism _forces_ the user to have
> > different environments on the same box - there's no choice.
> > 
> > Which is, as Al says, just like environment variables.
> > 
> > But not like files - if I create a file called $HOME/foo, I expect
> > that I can access it from a different login.  I might want to have
> > different environments, but that's not the _default_ when dealing with
> > files.
> > 
> > The question is whether private user-mounts should, by default, behave
> > more like environment variables or more like files.
> 
> I think you're a little confused.

No, I'm not.

Here's a perhaps more illustrative example.  My bookmarks in
~/.ncftp/bookmarks are not per session, they're per user.  They're not
"global" as in shared by all users in the usual sense.  (Yes, the file
is in a shared namespace, but other users won't be using it when they
type "ncftp".)

The _concept_ "my Ncftp bookmarks" is per-user, and bookmarks created
in one session are immediately usable in another session.

That's what I mean when I say "more like files".

Environment variables are not like that, bookmarks are.

Rephrasing the question: The question is whether private user-mounts
should, by default, behave more like environment variables or more
like bookmarks.

It's a user interface question, not a technical question.  Understand?

I think the user interface is more intuitive when private user-mounts
appear across all sessions shared by the same user.  That doesn't
preclude a non-default option to turn that off.

And here's _why_ I think that's more intuitive: people expect things
which appear in the filesystem to be visible across all sessions.
User-mounts certainly are visible in the filesystem.

> Files are a global ressource and as
> such it makes sense to see them everywhere.

No, files are not seen everywhere, as evidenced by the existence of
namespaces...  They're seen everywhere within a particular namespace.
And that namespace is determined by userspace policy...

> But you're not arguing for making the namespace a global ressource
> (again), but a per-user one, which has no precedence.

As a user interface, it has the precedence of bookmarks, cookies,
options in dotfiles...

I am arguing for making namespaces a global resource, which can be
joined and accessed by userspace however it likes.

Which makes it a policy entirely settable by userspace tools.

(And /proc/NNN/root is _very_ close to providing that.  It seems that
it just works as expected when the permission checks are removed).

The fact that I'd personally use namespaces in a per-user way is a
policy decision.  I use ssh-agent in a per-user way too, but that's my
choice, and other users can use it however they want.

-- Jamie

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Christoph Hellwig]

On Sat, Apr 30, 2005 at 04:01:11PM +0100, Jamie Lokier wrote:
> > > The question is whether private user-mounts should, by default, behave
> > > more like environment variables or more like files.
> > 
> > I think you're a little confused.
> 
> No, I'm not.
> 
> Here's a perhaps more illustrative example.  My bookmarks in
> ~/.ncftp/bookmarks are not per session, they're per user.

They're first a global resource - the file exist everywhere.  The only
think that makes it per-user is how ncftp interprets them.  By looking
into looking into /tmp/$SID/ncftp/bookmarks it could be made per-session.
(although that'd be totally useless of course)

> Rephrasing the question: The question is whether private user-mounts
> should, by default, behave more like environment variables or more
> like bookmarks.
> 
> It's a user interface question, not a technical question.  Understand?

It's very much a technical/philosophical question.  The user interface
isn't a thing that just happens out of thin air, there must be an
implementation behind it.

And in UNIX our traditional model for this kinds of things is to be per-
session, initialized by per-user values.  At this point we have an user
interface, and it's a well-understood one that works very well for similar
things.

Mount bind filehandle (Was: Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call)

[Jan Hudec]

[-- Attachment #1: Type: text/plain, Size: 2323 bytes --]

On Wed, Apr 20, 2005 at 18:09:21 +0100, Al Viro wrote:
> On Wed, Apr 20, 2005 at 09:51:26AM -0700, Ram wrote:
> > Reading through the thread I assume the requirement is:
> > 
> > 1) A User being able to create his own VFS-mount environment 
> > 2) being able to use the same VFS-mount environment from 
> >     multiple login sessions.
> > 3) Being able to switch some processes to some other
> >       VFS-mount environment.
> 
> Excuse me, but could somebody give coherent rationale for such requirements?
> _Especially_ for joining existing group by completely unrelated process -
> something we don't do for any other component of process.

I think I can. And I think I can modify the proposal to something a bit
more sane.

The problem is: The mount should be accessible only by processes started
  by the authorized user, but not by other user, including root, who is
  capable of changing their uid to the authorized user's id.

The solution can be: The mount is only accessible to the process group
  of that user's session. That's easy -- the login process is created
  with new namespace.

  Now how to allow the user to have that mountpoint accessible from all
  sessions? Well, we can already pass open file descriptor to files
  inside that mount to unrelated processes along unix domain sockets. So
  what is left is being able to mount --bind a directory by it's
  filehandle (since it does not have a path in our namespace).

  This allows creating a "mount-agent", that would work similar to
  ssh-agnet or gpg-agent, but instead of passing secret keys, it would
  pass descriptors to that user's mount roots and it's client would bind
  them. This agent can do whatever authentication is deemed appropriate
  for that mountpoint.

  Note however, that it's really hard to protect something against root,
  because root can ptrace any process.

Well, being able to mount bind file descriptor might be useful for other
purposes as well and should not be hard to do. Unless you or somebody
finds a security problem with it, but I don't see any. Process having
a directory handle can chdir there anyway, so this does not add it extra
access.

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Mount bind filehandle (Was: Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call)

[Christoph Hellwig]

On Thu, Apr 21, 2005 at 09:33:20AM +0200, Jan Hudec wrote:
> I think I can. And I think I can modify the proposal to something a bit
> more sane.
> 
> The problem is: The mount should be accessible only by processes started
>   by the authorized user, but not by other user, including root, who is
>   capable of changing their uid to the authorized user's id.
> 
> The solution can be: The mount is only accessible to the process group
>   of that user's session. That's easy -- the login process is created
>   with new namespace.

That doesn't make sense.  A process with sufficient capabilities (aka root)
can do things including reading or modifying kernel memory and can
access your namespace always, no matter how difficult you're trying to make
it.

Re: Mount bind filehandle (Was: Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call)

[Jan Hudec]

[-- Attachment #1: Type: text/plain, Size: 1986 bytes --]

On Thu, Apr 21, 2005 at 09:09:01 +0100, Christoph Hellwig wrote:
> On Thu, Apr 21, 2005 at 09:33:20AM +0200, Jan Hudec wrote:
> > I think I can. And I think I can modify the proposal to something a bit
> > more sane.
> > 
> > The problem is: The mount should be accessible only by processes started
> >   by the authorized user, but not by other user, including root, who is
> >   capable of changing their uid to the authorized user's id.
> > 
> > The solution can be: The mount is only accessible to the process group
> >   of that user's session. That's easy -- the login process is created
> >   with new namespace.
> 
> That doesn't make sense.  A process with sufficient capabilities (aka root)
> can do things including reading or modifying kernel memory and can
> access your namespace always, no matter how difficult you're trying to make
> it.

Yes, I know. Actually, in the mail you cite, there was also writte:
> >   Note however, that it's really hard to protect something against root,
> >   because root can ptrace any process.

So determined attacker with root access will break in (actually,
determined attacker with root access can read your ssh keys from your
running ssh session too -- te fact you fuse-mount it does not increase
his chances).

However, there are other reasons mentioned in this thread, why private
namespaces are useful. They can't be corrupted by misconfigured stuff,
don't confuse other (broken) stuff and such. And after all while the
proposal is inspired by this issue, it just means a generic extension to
bind mounts that could be useful for other applications. Sometimes
a program, for reliability or security reasons, need to work with
directory handles -- and this is a way to reliably assign them a path
instead of finding out the current one, which can change under their
hands.

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Bryan Henderson]

>How about making namespace's as first class objects with some associated
>name or device in the device tree having owner/permissions etc.  any
>process which forks off a namespace shall create the
>device node for the namespace.  If some other process wants to use
>the same namespace, it can do so by attaching itself to the namespace
>dynamically? Offcourse children processes inherit the same namespace.

For the issues being discussed here, I don't think that's materially 
different from what we started with; it has the same issue concerning 
whether a user should be allowed to change his namespace and whether a 
process' namespace should change automatically when another process does 
something.

Here's one more proposal, kind of a compromise among various previous 
ones.

  - When you mount(), you say whether the names should be visible by 
default or not.  It takes system privilege to make them visible by 
default, but an ordinary user can mount a willing filesystem over a 
directory he's permitted to modify unconditionally, invisible by default

  - A process can explicitly request to see an invisible-by-default 
mounted filesystem.  Anyone can do this, but permissions on the root 
directory of the mount determine if he can actually see anything.

  - A process inherits the parent's namespace (i.e. sees the mounts the 
parent does).

This accomplishes:

  - not much of a philosophical break from where we are now.

  - users can mount their own stuff without system privilege.

  - no one, not even a fully permitted administrative process, sees user 
junk by default.

  - setuid programs see standard files where the system administrator put 
them.

  - setuid programs see user files where the user put them.

  - multiple processes, with or without the same uid, can see user-mounted 
files if they want.

  - a process can opt not to see user-mounted files, even if it has the 
same uid as processes that do.

I'm not saying how I would implement this; there's enough discussion over 
the desired result that I thought we should start there.

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

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Miklos Szeredi]

> For the issues being discussed here, I don't think that's materially 
> different from what we started with; it has the same issue concerning 
> whether a user should be allowed to change his namespace and whether a 
> process' namespace should change automatically when another process does 
> something.
> 
> Here's one more proposal, kind of a compromise among various previous 
> ones.
> 
>   - When you mount(), you say whether the names should be visible by 
> default or not.  It takes system privilege to make them visible by 
> default, but an ordinary user can mount a willing filesystem over a 
> directory he's permitted to modify unconditionally, invisible by default

I like the idea of invisible mountpoints.  It doesn't even sound as if
it would be hard to implement, although Al will surely find a million
reasons why it's problematic ;)

>   - A process can explicitly request to see an invisible-by-default 
> mounted filesystem.  Anyone can do this, but permissions on the root 
> directory of the mount determine if he can actually see anything.

How would you request to make the mountpoint visible from _any_
program.  It's not acceptable to expect every program to include a
menu, command, etc. to be able to modify the visibility of
mountpoints.

Would it not be better if you could specify the visibility policy when
mounting?  Something simple like the user-group-other permission
modell would do nicely.  That would also have the advantage of being
bound to the mountpoint, not the process.

Miklos

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Bryan Henderson]

>How would you request to make the mountpoint visible from _any_
>program.  It's not acceptable to expect every program to include a
>menu, command, etc. to be able to modify the visibility of
>mountpoints.

OK, I overlooked the problem of having to add commands to the shell and 
everything else.  While there's plenty of precedent for this style 
(current directory, ulimits, umask), I wouldn't like to extend it, even to 
adding a command to Bash.  But it could follow the 'nice' and 'renice' 
model.

>Would it not be better if you could specify the visibility policy when
>mounting?  Something simple like the user-group-other permission
>model would do nicely.  That would also have the advantage of being
>bound to the mountpoint, not the process.

I just don't think that gives you enough policy flexibility.  If processes 
can control visibility on a per-process basis independent from the mount 
action, they can use a much greater variety of policy, and do it in user 
space.

As for user-group-other, let me first point out that this whole namespace 
discussion started when a design based on actual file permission bits, but 
not a true implementation of Unix security (root didn't get carte blanche) 
was found unpalatable by some.  So as you say, it would be something 
_like_ the permission model, not a part of it.

We've been straining against the limitations of user/group/other for 
decades.  Sophisticated systems don't even use them for file permissions. 
So I hesitate to tie anything else to them.

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

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Miklos Szeredi]

> OK, I overlooked the problem of having to add commands to the shell and 
> everything else.  While there's plenty of precedent for this style 
> (current directory, ulimits, umask), I wouldn't like to extend it, even to 
> adding a command to Bash.  But it could follow the 'nice' and 'renice' 
> model.

OK.  The user could then script the mount to change visibility for all
current processes with his uid, and new programs would inherit the
visibility.

It would still not work for ftp-server style programs, which are
started from an independent daemon, yet after login run with the
user's credentials, and hence I would expect to run with the user's
"namespace".

> >Would it not be better if you could specify the visibility policy when
> >mounting?  Something simple like the user-group-other permission
> >model would do nicely.  That would also have the advantage of being
> >bound to the mountpoint, not the process.
> 
> I just don't think that gives you enough policy flexibility.  If processes 
> can control visibility on a per-process basis independent from the mount 
> action, they can use a much greater variety of policy, and do it in user 
> space.

If used in conjuction with CLONE_NEWNS it would have all the needed
flexibility.

> As for user-group-other, let me first point out that this whole namespace 
> discussion started when a design based on actual file permission bits, but 
> not a true implementation of Unix security (root didn't get carte blanche) 
> was found unpalatable by some.  So as you say, it would be something 
> _like_ the permission model, not a part of it.

Yes, that is what I meant.

> We've been straining against the limitations of user/group/other for 
> decades.  Sophisticated systems don't even use them for file permissions. 

But the non-sophisticated case is by far the most abundant.  And for
that the traditional UNIX permission modell is not only good enough,
it is in fact _better_ than any sophisticated access control mechanism
because of it's _simplicity_.

Miklos

[RFC][patch] mount permissions (was: [RFC][2.6 patch] Allow ...)

[Miklos Szeredi]

Following up Bryan Henderson's idea of invisible mounts and my
conviction that you don't need per-process selection for visibility,
here's a proof of concept patch.

It adds a new mount flag MNT_NOOTHER/MS_NOOTHER.  If this flag is set,
then the mount is only visible to it's "owner".

The owner is set to current->fsuid at mount time (hack).

I tested it with a primitive mount utility (included at the end), and
everything seems to work as expected.

If something like this is acceptable, it would be a perfect
replacement for the current permission based mount hiding in FUSE.

Comments?

Thanks,
Miklos

 fs/namespace.c        |   21 +++++++++++++++++++--
 include/linux/fs.h    |    1 +
 include/linux/mount.h |    2 ++
 3 files changed, 22 insertions(+), 2 deletions(-)

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 14:59:24.000000000 +0100
+++ linux-2.6.11/fs/namespace.c	2005-04-21 15:26:03.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_NOOTHER) ||
+		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;
 		}
@@ -234,6 +244,7 @@ static int show_vfsmnt(struct seq_file *
 		{ MNT_NOSUID, ",nosuid" },
 		{ MNT_NODEV, ",nodev" },
 		{ MNT_NOEXEC, ",noexec" },
+		{ MNT_NOOTHER, ",noother" },
 		{ 0, NULL }
 	};
 	struct proc_fs_info *fs_infop;
@@ -252,6 +263,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_NOOTHER)
+		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");
@@ -807,6 +820,8 @@ int do_add_mount(struct vfsmount *newmnt
 		goto unlock;
 
 	newmnt->mnt_flags = mnt_flags;
+	if (mnt_flags & MNT_NOOTHER)
+		newmnt->mnt_uid = current->fsuid;
 	err = graft_tree(newmnt, nd);
 
 	if (err == 0 && fslist) {
@@ -1033,7 +1048,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_NOOTHER)
+		mnt_flags |= MNT_NOOTHER;
+	flags &= ~(MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_NOOTHER|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 14:59:29.000000000 +0100
+++ linux-2.6.11/include/linux/fs.h	2005-04-21 13:32:41.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_NOOTHER	256
 #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-24 22:33:51.000000000 +0100
+++ linux-2.6.11/include/linux/mount.h	2005-04-21 12:50:42.000000000 +0200
@@ -19,6 +19,7 @@
 #define MNT_NOSUID	1
 #define MNT_NODEV	2
 #define MNT_NOEXEC	4
+#define MNT_NOOTHER	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;

===File ~/cc/mounttest.c====================================
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/mount.h>
#include <sys/fsuid.h>

int main(int argc, char *argv[])
{
    if(argc != 6) {
        fprintf(stderr, "usage: %s dev dir type flags opts\n", argv[0]);
        return 1;
    }
    setfsuid(getuid());
    if(mount(argv[1], argv[2], argv[3], atoi(argv[4]), argv[5]) == -1) {
        perror("mount");
        return 1;
    }
    return 0;
}
============================================================

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Bryan Henderson]

>It would still not work for ftp-server style programs,

True.  Users might want the mounts to show up to an ftp or not, and this 
handles only "not."

>If used in conjuction with CLONE_NEWNS it would have all the needed
>flexibility.

I don't see how.  What if my policy is that processes with a certain 
process name (command) see the mount?  What if my policy is that users in 
a certain filesystem ACL can see it?  That's the kind of flexibility you 
can't get if the policy is set up via the mount() system call.

>But the non-sophisticated case is by far the most abundant.  And for
>that the traditional UNIX permission modell is not only good enough,
>it is in fact _better_ than any sophisticated access control mechanism
>because of it's _simplicity_.

Absolutely.  And that's why I speak of flexibility.  Let the simple users 
have their simple U-G-0 and the more creative ones do something more 
complex.

I'm not opposed, by the way, to an implementation that just does U-G-O (or 
even just U) if it's done in a way amenable to future extension.

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

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Al Viro]

On Wed, Apr 20, 2005 at 11:57:23AM -0700, Bryan Henderson wrote:
>   - When you mount(), you say whether the names should be visible by 
> default or not.  It takes system privilege to make them visible by 
> default, but an ordinary user can mount a willing filesystem over a 
> directory he's permitted to modify unconditionally, invisible by default

That assumes that everyone has the same stuff in the same places.  I.e.
that there is a universal tree with different subset hidden from different
processes.  But that is obviously a wrong approach - e.g. it loses ability
to bind different stuff on the same place in different namespaces.  _And_
it doesn't work accross the host boundary for even more obvious reasons
(/bin/sh is going to be a different binary on i386, alpha and sparc boxen,
no matter what).

	IOW, notion that every directory has its "real" absolute pathname
(and that's what your approach boils down to) won't match the reality
anyway.

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Bryan Henderson]

>That assumes that everyone has the same stuff in the same places.  I.e.
>that there is a universal tree with different subset hidden from 
different
>processes.  But that is obviously a wrong approach - e.g. it loses 
ability
>to bind different stuff on the same place in different namespaces.

Aren't you trying to boil another egg in my pot?  In Linux today, everyone 
(every process on the same Linux system, that is) has the same stuff in 
the same place.  I'm trying to propose an incremental improvement, and 
relaxing that restriction isn't part of it.

The only change would be that some processes wouldn't have some stuff in 
_any_ place.  (Either because they didn't ask to see a particular mount, 
or because they did and it covered up something else).

>IOW, notion that every directory has its "real" absolute pathname
>(and that's what your approach boils down to) won't match the reality
>anyway.

Not sure which reality you're talking about.  I don't think a directory 
has a real absolute pathname, because I think the person who mounts the 
filesystem that contains it chooses part of its absolute pathname for the 
lifetime of the mount.  But as between multiple processes on the same 
system at the same time, yeah, the directory has one name.

(statements above have to be modified for chroot, btw).

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

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Al Viro]

On Wed, Apr 20, 2005 at 05:23:10PM -0700, Bryan Henderson wrote:
> >That assumes that everyone has the same stuff in the same places.  I.e.
> >that there is a universal tree with different subset hidden from 
> different
> >processes.  But that is obviously a wrong approach - e.g. it loses 
> ability
> >to bind different stuff on the same place in different namespaces.
> 
> Aren't you trying to boil another egg in my pot?  In Linux today, everyone 
> (every process on the same Linux system, that is) has the same stuff in 
> the same place.

Incorrect.  We have working namespaces right now and had them for quite
a while.  And no, they do not suffer from such braindamage.  Usable
right now and yes, I *do* use that.

> I'm trying to propose an incremental improvement, and 
> relaxing that restriction isn't part of it.

Funny, how that *introduces* the restriction you are talking about...

> lifetime of the mount.  But as between multiple processes on the same 
> system at the same time, yeah, the directory has one name.

Care to experiment?  Create a new namespace and do different bindings at
the same place in old and new one.  Or mount --move in either, etc.

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Christoph Hellwig]

On Wed, Apr 20, 2005 at 05:23:10PM -0700, Bryan Henderson wrote:
> >That assumes that everyone has the same stuff in the same places.  I.e.
> >that there is a universal tree with different subset hidden from 
> different
> >processes.  But that is obviously a wrong approach - e.g. it loses 
> ability
> >to bind different stuff on the same place in different namespaces.
> 
> Aren't you trying to boil another egg in my pot?  In Linux today, everyone 
> (every process on the same Linux system, that is) has the same stuff in 
> the same place.

No.  I'm running various different namespace here, as part of a command to
setup chroots sanely.

> Not sure which reality you're talking about.  I don't think a directory 
> has a real absolute pathname, because I think the person who mounts the 
> filesystem that contains it chooses part of its absolute pathname for the 
> lifetime of the mount.  But as between multiple processes on the same 
> system at the same time, yeah, the directory has one name.

No.

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Ram]

On Wed, 2005-04-20 at 11:57, Bryan Henderson wrote:
> >How about making namespace's as first class objects with some associated
> >name or device in the device tree having owner/permissions etc.  any
> >process which forks off a namespace shall create the
> >device node for the namespace.  If some other process wants to use
> >the same namespace, it can do so by attaching itself to the namespace
> >dynamically? Offcourse children processes inherit the same namespace.

> For the issues being discussed here, I don't think that's materially 
> different from what we started with; it has the same issue concerning 
> whether a user should be allowed to change his namespace and whether a 
> process' namespace should change automatically when another process does 
> something.
Well I am not aware of issues that can arise if a user is allowed to
change to some namespace for which it has permission to switch. I am 
wondering what can those be. Just for clarity under the assumption that
there wont be any security issues with this proposal, I will run through
a typical case on how this proposal can be used to solve the FUSE needs.

Ok let me explain how my proposal attempts to solves the problem:

A user 'ram' creates a namespace 'n1' with a device node /dev/n1 having
permission 700 owned by the user 'ram'. The user than tailors his
namespace with a bunch of mount/umount/binds etc to meet his
requirement.  All the processes that fork off this process see this same
setup.

Now 'ram' again logs-in to the same machine from a different terminal.
He gets the default system-namespace to begin with. But he runs a shell
built-in command 'chnamespace n1' and hence forth it will hook on to the
new namespace and see the same environment as seen by the other login.

And this login can be automated to see the 'n1' namespace by default by
making the login process to pick the 'n1' namespace right from the
beginning (if one exists) by looking at the some configuration file like
/etc/password or maybe /etc/shadow. 

Any other user who wants to attach to the same namespace can try to,
but if the permissions are denied it wont be able to. 

> 
> Here's one more proposal, kind of a compromise among various previous 
> ones.
> 
>   - When you mount(), you say whether the names should be visible by 
> default or not.  It takes system privilege to make them visible by 
> default, but an ordinary user can mount a willing filesystem over a 
> directory he's permitted to modify unconditionally, invisible by default
>   - A process can explicitly request to see an invisible-by-default 
> mounted filesystem.  Anyone can do this, but permissions on the root 
> directory of the mount determine if he can actually see anything.
> 
>   - A process inherits the parent's namespace (i.e. sees the mounts the 
> parent does).

Trying to understand your proposal to see how it could be used to solve
the problem faced by the FUSE project.  Are you trying to use a single
namespace with invisible mounts capability? 

RP

> 
> This accomplishes:
> 
>   - not much of a philosophical break from where we are now.
> 
>   - users can mount their own stuff without system privilege.
> 
>   - no one, not even a fully permitted administrative process, sees user 
> junk by default.
> 
>   - setuid programs see standard files where the system administrator put 
> them.
> 
>   - setuid programs see user files where the user put them.
> 
>   - multiple processes, with or without the same uid, can see user-mounted 
> files if they want.
> 
>   - a process can opt not to see user-mounted files, even if it has the 
> same uid as processes that do.
> 
> I'm not saying how I would implement this; there's enough discussion over 
> the desired result that I thought we should start there.
> 
> --
> Bryan Henderson                          IBM Almaden Research Center
> San Jose CA                              Filesystems
> 

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Bryan Henderson]

>Well I am not aware of issues that can arise if a user is allowed to
>change to some namespace for which it has permission to switch.

I think I misunderstood your proposal.

>A user 'ram' creates a namespace 'n1' with a device node /dev/n1 having
>permission 700 owned by the user 'ram'. The user than tailors his
>namespace with a bunch of mount/umount/binds etc to meet his
>requirement.

How does that address the setuid problem -- that a setuid program is 
installed with the expectation that when it runs, certain names will 
identify certain files (e.g. /etc/shadow)?  But also that certain other 
names will identify a file of the invoker's choosing?

>Trying to understand your proposal to see how it could be used to solve
>the problem faced by the FUSE project.  Are you trying to use a single
>namespace with invisible mounts capability? 

Essentially.  It's a compromise.  A user can customize his namespace, but 
only within limits that preserve the integrity of the system.

Technically, we have to admit it's not one namespace today or with 
invisible mounts.  Because of the way mounts cover up mountpoints, it's 
technically possible for two processes to see different files as the same 
name, if one opened the directory before a mount and the other after. 
"Mounting over" is a curse.

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

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Ram]

On Wed, 2005-04-20 at 17:42, Bryan Henderson wrote:
> >Well I am not aware of issues that can arise if a user is allowed to
> >change to some namespace for which it has permission to switch.
> 
> I think I misunderstood your proposal.
> 
> >A user 'ram' creates a namespace 'n1' with a device node /dev/n1 having
> >permission 700 owned by the user 'ram'. The user than tailors his
> >namespace with a bunch of mount/umount/binds etc to meet his
> >requirement.
> 
> How does that address the setuid problem -- that a setuid program is 
> installed with the expectation that when it runs, certain names will 
> identify certain files (e.g. /etc/shadow)?  But also that certain other 
> names will identify a file of the invoker's choosing?

the new namespace 'n1' though created by the user 'ram', carries the
same restrictions to 'ram' . So 'ram' will not be able to mount
something else on /bin or /sbin or anyother directory that it does not
own, even though its done in its own namespace. Hence I dont see how a
attacker would be able fool a malicious setuid program into a genuine
setuid program. hope this is the concern you were talking about. right?

RP


> 
> >Trying to understand your proposal to see how it could be used to solve
> >the problem faced by the FUSE project.  Are you trying to use a single
> >namespace with invisible mounts capability? 
> 
> Essentially.  It's a compromise.  A user can customize his namespace, but 
> only within limits that preserve the integrity of the system.
> 
> Technically, we have to admit it's not one namespace today or with 
> invisible mounts.  Because of the way mounts cover up mountpoints, it's 
> technically possible for two processes to see different files as the same 
> name, if one opened the directory before a mount and the other after. 
> "Mounting over" is a curse.
> 
> --
> Bryan Henderson                          IBM Almaden Research Center
> San Jose CA                              Filesystems

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Bryan Henderson]

>> But that shouldn't be the only option - because it would be horrible
>> to use.  If I login on multiple terminals, I normally want to mount
>> filesystems in /home/jamie/mnt on one terminal, and use them on 
another.
>
>And when you log in on several terminals you usually want same $PATH.
>You don't do that by sharing VM between shell processes, do you?

I share Al's view, and would expand:  You'd _like_ to be able to add 
something to your namespace once and have it show up in multiple process' 
namespaces, but you wouldn't expect it, because Unix has been horrible to 
use in that way forever.  I am frequently frustrated when I decide to 
change my environment either by setting an environment variable or shell 
variable or alias, and I have to do it separately in every existing shell. 
 And forget about the background jobs.  But at least it's consistent.  And 
there are other times when I exploit the fact that I can set something 
differently in different shells of the same user.

We do have a few areas where a group of processes can share the same 
kernel state, but it's always based on common ancestry.  It would take a 
major new concept to have a different kind of group of processes for 
namespace purposes, and then we probably wouldn't want to base it on uid, 
because uid means other things already.  Why tie them together?

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

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Jan Hudec]

[-- Attachment #1: Type: text/plain, Size: 961 bytes --]

On Wed, Apr 20, 2005 at 10:45:58 +0100, Jamie Lokier wrote:
> Al Viro wrote:
> > Most of the code is already there - do_fork() has to do such stuff anyway.
> > So how about adding sys_unshare(flags) that would do that job?  Flags would
> > correspond to those of clone(2), except that all these guys would be
> > "what do we unshare" instead of "what do we leave shared".
> 
> That would let a program split off into its own namespace, but that's
> not really what's needed for FUSE.
> 
> For FUSE, what's needed is that a user can mount something, and the
> mounted fs is visible only to that user, but it's visible to _all_ of
> the user's processes.

Including root's su to that user...
Keeping information in a process group is the *only* way to actually
lock out root. That is, except some kind of keyring in kernel.

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Jamie Lokier]

Jan Hudec wrote:
> > For FUSE, what's needed is that a user can mount something, and the
> > mounted fs is visible only to that user, but it's visible to _all_ of
> > the user's processes.
> 
> Including root's su to that user...
> Keeping information in a process group is the *only* way to actually
> lock out root.

If root is _intending_ to view the user's data, it will succeed.

Keeping them in a process group won't prevent that: root can look at
the data accessible by any process (via ptrace or /dev/mem).

The problem most clearly illustrating the need for private user data
is sshfs, or anything which mounts over ssl/tls.

> That is, except some kind of keyring in kernel.

For secure user data, as in sshfs, that's the only real solution: a
keyring in kernel which cannot be accessed simply by calling su, and
which must be accessed to gain access to the mounted directory.

Which is no different from securing user data when scp+ssh-agent is used.

-- Jamie

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Jan Hudec]

[-- Attachment #1: Type: text/plain, Size: 1421 bytes --]

On Wed, Apr 20, 2005 at 23:13:58 +0100, Jamie Lokier wrote:
> Jan Hudec wrote:
> > > For FUSE, what's needed is that a user can mount something, and the
> > > mounted fs is visible only to that user, but it's visible to _all_ of
> > > the user's processes.
> > 
> > Including root's su to that user...
> > Keeping information in a process group is the *only* way to actually
> > lock out root.
> 
> If root is _intending_ to view the user's data, it will succeed.
> 
> Keeping them in a process group won't prevent that: root can look at
> the data accessible by any process (via ptrace or /dev/mem).
> 
> The problem most clearly illustrating the need for private user data
> is sshfs, or anything which mounts over ssl/tls.
> 
> > That is, except some kind of keyring in kernel.
> 
> For secure user data, as in sshfs, that's the only real solution: a
> keyring in kernel which cannot be accessed simply by calling su, and
> which must be accessed to gain access to the mounted directory.
> 
> Which is no different from securing user data when scp+ssh-agent is used.

Yes. You are right. I realized that too.

By the way, IIRC so far the root can access all kernel memory too via
/dev/kmem. So the limiting of root's rights would have to be limited
a bit more yet.

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Jamie Lokier]

Jan Hudec wrote:
> By the way, IIRC so far the root can access all kernel memory too via
> /dev/kmem. So the limiting of root's rights would have to be limited
> a bit more yet.

On some hardened systems, root is not allowed access to /dev/kmem.

-- Jamie

Hiding secrets from root (Was: Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call)

[Jan Hudec]

[-- Attachment #1: Type: text/plain, Size: 749 bytes --]

On Thu, Apr 21, 2005 at 19:44:56 +0100, Jamie Lokier wrote:
> Jan Hudec wrote:
> > By the way, IIRC so far the root can access all kernel memory too via
> > /dev/kmem. So the limiting of root's rights would have to be limited
> > a bit more yet.
> 
> On some hardened systems, root is not allowed access to /dev/kmem.

That sure makes sense. Still the secret keys must either never leave
kernel (which would need all the encryption, decryption and checking
code in kernel), or they must be protected in userland too. Which means
the process has to be protected against being ptraced or inspected
through /dev/mem.

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Hiding secrets from root (Was: Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call)

[Jamie Lokier]

Jan Hudec wrote:
> On Thu, Apr 21, 2005 at 19:44:56 +0100, Jamie Lokier wrote:
> > Jan Hudec wrote:
> > > By the way, IIRC so far the root can access all kernel memory too via
> > > /dev/kmem. So the limiting of root's rights would have to be limited
> > > a bit more yet.
> > 
> > On some hardened systems, root is not allowed access to /dev/kmem.
> 
> That sure makes sense. Still the secret keys must either never leave
> kernel (which would need all the encryption, decryption and checking
> code in kernel), or they must be protected in userland too. Which means
> the process has to be protected against being ptraced or inspected
> through /dev/mem.

That's right.  Protecting users' private data from access by the
administrators on a multi-user system is, not surprisingly, hard....

-- Jamie

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Eric Van Hensbergen]

On 4/19/05, Al Viro <viro@parcelfarce.linux.theplanet.co.uk> wrote:
> On Tue, Apr 19, 2005 at 06:53:29PM -0500, Eric Van Hensbergen wrote:
> > On 4/19/05, Al Viro <viro@parcelfarce.linux.theplanet.co.uk> wrote:
> 
> a) ability to create a private namespace without forking anything - sure,
> that would be useful.  However, that's not something I would push into
> mount(2) (already overloaded to hell and back).
>

That's fair, just though it might be easier to slide in than a new
system call.  Should have known better -- sliding things in is never a
good idea.

> 
> There used to be a kinda-sorta agreement on a new syscall:
>         unshare(bitmap)
> with arguments like those of clone(2).  That's not just for namespaces -
> e.g. you might legitimately want to unshare VM in a thread and leave the
> rest alone.  Or unshare ->fs (i.e. uncouple cwd from the rest of group).
> 
> Most of the code is already there - do_fork() has to do such stuff anyway.
> So how about adding sys_unshare(flags) that would do that job?  Flags would
> correspond to those of clone(2), except that all these guys would be
> "what do we unshare" instead of "what do we leave shared".
> 

Okay, I'll try to work something up today and post a straw man here.

>
> b) I _really_ don't like the idea of messing with the parent.  Make it
> a shell builtin if you want to affect shell behaviour; the same reason
> why cd is a builtin and not an external command.
>

Yeah, that was really slimy, just wanted something that would be more
accessible to end users without having to affect changes to lots of
applications.  A somewhat less slimy method would be to expose
something in /proc, but I suppose that is a much more theologically
charged option.
 
> c) I would be really, really careful with implications of "let user
> do whatever he wants" - that certainly should include bindings and
> that can create heaps of fun for suid stuff.  More comments when
> I get around to digging through FUSE thread...

I agree, but I want to understand all the issues and see if we can
work out a solution which gives the user some ability to leverage
mount/bind in private namespaces.  I am trying to get more of a Plan 9
like environment under Linux, but understand the existence of a root
uid will require a lot more restrictions.  See my comments in the
later portions of the FUSE thread on a user-mount-permissions file
that would allow admins to define policies on what and where users
could mount/bind (and with what flags).

       -eric

Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Eric Van Hensbergen]

On 4/20/05, Eric Van Hensbergen <ericvh@gmail.com> wrote:
> 
> Yeah, that was really slimy, just wanted something that would be more
> accessible to end users without having to affect changes to lots of
> applications.  A somewhat less slimy method would be to expose
> something in /proc, but I suppose that is a much more theologically
> charged option.
> 

I take it back, the more I think about it /proc is even more slimy. 
Forget I said it.

       -eric