Hi Junjiro,

I converted Bhushan Jain's changes into a git patch, so you can easy
apply it to your tree.

Florian

Am 17.07.2013 23:58, schrieb Bhushan Jain:
> Hi,
> Thanks for letting me know about  this discussion.
> Serge is correct. By allowing this flag, an un-privileged user can mount aufs 
> filesystem within the user namespace and the administrator needs to be aware 
> of this. However, I am not sure about the harm in letting an unprivileged 
> user mount the aufs filesystem. The file permissions cannot be violated even 
> in a user namespace.
>
> As Eric said:
> "The rule with filesystems like that is mounting them needs to be no more 
> dangerous than bind mounting them."
>
> And I think, this is true for aufs filesystem. Please correct me if I am 
> wrong.
>
> Thanks,
> Bhushan
> ________________________________________
> From: sf...@users.sourceforge.net [sf...@users.sourceforge.net]
> Sent: Wednesday, July 17, 2013 9:57 AM
> To: Bhushan Jain; aufs-users@lists.sourceforge.net
> Subject: Re: Aufs support for Linux User namespace
>
> sf...@users.sourceforge.net:
>> Bhushan Jain:
>>> Attached is a sample code that creates a user namespace and maps the un-pri=
>>> vileged user to root within the namespace.=0A=
>>> The user namespace can be used for sandboxing. Having aufs support within t=
>>> he user namespace can help create a chroot environment where multiple direc=
>>> tories are united into a single filesystem.=0A=
>> Thanks for the sample code.
>> Personally, user-ns is not attractive for me, at the same time I don't
>> have strong objection. So I will merge your patch.
> Intrestingly, very similar discussion happened on LKML.
> See this and its thread.
>         Date: Tue, 16 Jul 2013 14:29:20 -0500
>         From: Serge Hallyn <serge.hal...@ubuntu.com>
>         Subject: [PATCH RFC] allow some kernel filesystems to be mounted
>                 in a user namespace
>
> The patch sets FS_USERNS_MOUNT for debugfs, fuse and securityfs.
> But at the end of the thread, he wrote
>         Right so the specific problem this patch introduces is:  An admin who 
> is
>         using a distro kernel with these filesystems enabled but not mounted,
>         without this patch does not have to worry about unprivileged users 
> being
>         able to access the fs.  With this patch, he does.
>
>         Thanks everyone, I withdraw this patch.
>
> If such problem really exists, it might be better for aufs NOT to set
> FS_USERNS_MOUNT I suppose.
>
>
> J. R. Okajima
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk

>From 205fb5d18bb77c60b155808658e1ef146d0a2c8a Mon Sep 17 00:00:00 2001
From: Bhushan Jain <bpj...@cs.stonybrook.edu>
Date: Wed, 25 Sep 2013 11:15:14 +0200
Subject: [PATCH] aufs: add support for user namespaces

---
 fs/aufs/super.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/aufs/super.c b/fs/aufs/super.c
index 4f57ba0..be39ce4 100644
--- a/fs/aufs/super.c
+++ b/fs/aufs/super.c
@@ -984,7 +984,7 @@ static void aufs_kill_sb(struct super_block *sb)
 struct file_system_type aufs_fs_type = {
 	.name		= AUFS_FSTYPE,
 	/* a race between rename and others */
-	.fs_flags	= FS_RENAME_DOES_D_MOVE,
+	.fs_flags	= FS_RENAME_DOES_D_MOVE | FS_USERNS_MOUNT,
 	.mount		= aufs_mount,
 	.kill_sb	= aufs_kill_sb,
 	/* no need to __module_get() and module_put(). */
-- 
1.8.4

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk

Reply via email to