summarylogtreecommitdiffstats
path: root/ubuntu-unprivileged-overlayfs.patch
blob: cfa8009e71ef74a91962d3a777a4a45993bf14cf (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
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