nixpkgs/pkgs/os-specific/linux/kernel/ubuntu-unprivileged-overlayfs.patch
Paul Colomiets 84c0098117 Unprivileged overlayfs mounts kernel patch from ubuntu
This allows to create overlayfs mounts by unprivileged containers (i.e.
in user and mount namespace). It's super-useful for containers.

The patch is trivial as I understand from the patch description it's
does not have security implications (on top of what user namespaces
already have). And it's enabled in ubuntu long time ago. Here is a proof:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1357025
2015-09-26 00:42:16 +03:00

70 lines
2.4 KiB
Diff

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