mirror of
https://github.com/NixOS/nixpkgs.git
synced 2024-11-27 08:01:14 +00:00
84c0098117
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
70 lines
2.4 KiB
Diff
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
|
|
|