1
0
Fork 1
mirror of https://github.com/NixOS/nixpkgs.git synced 2024-11-22 13:41:26 +00:00

Merge pull request #10067 from tailhook/unprivileged_overlayfs

Unprivileged overlayfs mounts kernel patch from ubuntu
This commit is contained in:
Charles Strahan 2015-09-28 01:27:50 -05:00
commit a36ab12727
2 changed files with 74 additions and 0 deletions

View file

@ -68,6 +68,11 @@ rec {
patch = ./ubuntu-fan-4.patch;
};
ubuntu_unprivileged_overlayfs =
{ name = "ubuntu-unprivileged-overlayfs";
patch = ./ubuntu-unprivileged-overlayfs.patch;
};
tuxonice_3_10 = makeTuxonicePatch {
version = "2013-11-07";
kernelVersion = "3.10.18";

View file

@ -0,0 +1,69 @@
From 7415cb7b31569e9266229d4ebc79ccec4841ab04 Mon Sep 17 00:00:00 2001
From: Serge Hallyn <serge.hallyn@ubuntu.com>
Date: Fri, 7 Feb 2014 09:32:46 -0600
Subject: [PATCH] UBUNTU: SAUCE: Overlayfs: allow unprivileged mounts
Unprivileged mounting, here, refers to root in a non-initial user
namespace performing the mount. In particular, it requires
CAP_SYS_ADMIN toward the task's mounts namespace, alleviating
the concerns of manipulating mount environment for setuid-root
binaries on the host.
We refuse unprivileged mounting of most filesystem types because
we do not trust the in-kernel superblock parsers to correctly
handle malicious input.
However, overlayfs does not parse any user-provided data other
than the pathnames passed in. Therefore unprivileged mounting
of overlayfs should be safe.
Allowing unprivileged mounting of overlayfs filesystems would
allow Ubuntu Trusty users to create overlayfs-based container
snapshots, which would be a huge usability improvement.
This patch enables unprivileged mounting of overlayfs.
I tested a few simple combinations, and found that, when
doing (the equivalent of)
mount -t overlayfs -oupperdir=u,lowerdir=l l t
(u for upper, l for lower, t for target),
1. overlayfs mount is always allowed, regardless of ownership
of u, l, or t. However
2. Creation of new files is allowed so long as u is owned by
T. Otherwise, regardless of ownerships of l and t it is
denied. (This is expected; t was the mountpoint and
'disapears', so its ownership is irrelevant)
3. modification of a file 'hithere' which is in l but not yet
in u, and which is not owned by T, is not allowed, even if
writes to u are allowed. This may be a bug in overlayfs,
but it is safe behavior. It also will not cause a problem
for lxc since lxc will ensure that files are mapped into T's
namespace.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
---
fs/overlayfs/super.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
index 9473e79..50890c2 100644
--- a/fs/overlayfs/super.c
+++ b/fs/overlayfs/super.c
@@ -668,6 +668,7 @@ static struct file_system_type ovl_fs_type = {
.name = "overlayfs",
.mount = ovl_mount,
.kill_sb = kill_anon_super,
+ .fs_flags = FS_USERNS_MOUNT,
};
MODULE_ALIAS_FS("overlayfs");
--
2.1.0.rc1