[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070413041612.GC25877@MAIL.13thfloor.at>
Date: Fri, 13 Apr 2007 06:16:12 +0200
From: Herbert Poetzl <herbert@...hfloor.at>
To: "Serge E. Hallyn" <serue@...ibm.com>
Cc: Miklos Szeredi <miklos@...redi.hu>, containers@...ts.osdl.org,
viro@....linux.org.uk, linux-fsdevel@...r.kernel.org,
akpm@...ux-foundation.org, linuxram@...ibm.com,
linux-kernel@...r.kernel.org
Subject: Re: [patch 05/10] add "permit user mounts in new namespace" clone flag
On Thu, Apr 12, 2007 at 03:32:08PM -0500, Serge E. Hallyn wrote:
> Quoting Miklos Szeredi (miklos@...redi.hu):
> > From: Miklos Szeredi <mszeredi@...e.cz>
> >
> > If CLONE_NEWNS and CLONE_NEWNS_USERMNT are given to clone(2) or
> > unshare(2), then allow user mounts within the new namespace.
> > This is not flexible enough, because user mounts can't be enabled for
> > the initial namespace.
> >
> > The remaining clone bits also getting dangerously few...
ATM I think we do not have that many CLONE flags
available, so that this feature will have to wait
for a clone2/64 or similar ...
> > Alternatives are:
> >
> > - prctl() flag
> > - setting through the containers filesystem
> Sorry, I know I had mentioned it, but this is definately my least
> favorite approach.
>
> Curious whether are any other suggestions/opinions from the containers
> list?
question: how is mounting filesystems (loopback,
fuse, etc) secured in such way that the user
cannot 'create' device nodes with 'unfortunate'
permissions?
TIA,
Herbert
> thanks,
> -serge
>
> > Signed-off-by: Miklos Szeredi <mszeredi@...e.cz>
> > ---
> >
> > Index: linux/fs/namespace.c
> > ===================================================================
> > --- linux.orig/fs/namespace.c 2007-04-12 13:46:19.000000000 +0200
> > +++ linux/fs/namespace.c 2007-04-12 13:54:36.000000000 +0200
> > @@ -1617,6 +1617,8 @@ struct mnt_namespace *copy_mnt_ns(int fl
> > return ns;
> >
> > new_ns = dup_mnt_ns(ns, new_fs);
> > + if (new_ns && (flags & CLONE_NEWNS_USERMNT))
> > + new_ns->flags |= MNT_NS_PERMIT_USERMOUNTS;
> >
> > put_mnt_ns(ns);
> > return new_ns;
> > Index: linux/include/linux/sched.h
> > ===================================================================
> > --- linux.orig/include/linux/sched.h 2007-04-12 13:26:48.000000000 +0200
> > +++ linux/include/linux/sched.h 2007-04-12 13:54:36.000000000 +0200
> > @@ -26,6 +26,7 @@
> > #define CLONE_STOPPED 0x02000000 /* Start in stopped state */
> > #define CLONE_NEWUTS 0x04000000 /* New utsname group? */
> > #define CLONE_NEWIPC 0x08000000 /* New ipcs */
> > +#define CLONE_NEWNS_USERMNT 0x10000000 /* Allow user mounts in ns? */
> >
> > /*
> > * Scheduling policies
> > Index: linux/kernel/fork.c
> > ===================================================================
> > --- linux.orig/kernel/fork.c 2007-04-11 18:27:46.000000000 +0200
> > +++ linux/kernel/fork.c 2007-04-12 13:59:10.000000000 +0200
> > @@ -1586,7 +1586,7 @@ asmlinkage long sys_unshare(unsigned lon
> > err = -EINVAL;
> > if (unshare_flags & ~(CLONE_THREAD|CLONE_FS|CLONE_NEWNS|CLONE_SIGHAND|
> > CLONE_VM|CLONE_FILES|CLONE_SYSVSEM|
> > - CLONE_NEWUTS|CLONE_NEWIPC))
> > + CLONE_NEWUTS|CLONE_NEWIPC|CLONE_NEWNS_USERMNT))
> > goto bad_unshare_out;
> >
> > if ((err = unshare_thread(unshare_flags)))
> >
> > --
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> > the body of a message to majordomo@...r.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> _______________________________________________
> Containers mailing list
> Containers@...ts.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/containers
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists