Florian Klink:
> However, as we're not really sure about any possible security issues
> this could bring to aufs, it would probably the best to let users decide
> by adding a CONFIG_AUFS_USERNS_MOUNT option (attached with a fat warning
> that it's not really tested and could cause security issues).
My first approach was such like this.
+config AUFS_USERNS_MOUNT
+ bool "Allow userns root"
+ help
+ Userns mount to put AUFS into a chroot environment can be useful
+ while it as a security worry. This configuration sets an
+ internal flag FS_USERNS_MOUNT and allows userns unconditionally.
+ See the discussion in
+
http://www.mail-archive.com/aufs-users@lists.sourceforge.net/msg04266.html
+ and its thread. If you don't know what you are doing, leave it
+ N.
But later, I converted it to a module parameter. It is useful for users
to switch the bahaviour without recompile.
> It's interesting to note that during the preparation of the regular
> filesystems, FS_USERNS_MOUNT was not set for these filesystems, either:
> https://lkml.org/lkml/2012/9/21/561 . It's currently only set for
> devpts, proc, ramfs and sysfs.
Tmpfs too.
I can easily guess that all these fs are subject to be mounted under
user_ns. Also I guess, after hearing about the recent use-cases of
LXC/Docker, people may want to set FS_USERNS_MOUNT to aufs.
J. R. Okajima
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
