Message ID | 20140207153246.GA17617@sergelap |
---|---|
State | New |
Headers | show |
(CC:ing Miklos for further insight; Miklos, for reference the original email is: https://lists.ubuntu.com/archives/kernel-team/2014-February/038811.html) Hi, with the applied patch we can start overlayfs-based containers as an unprivileged user - however we can't delete files because we need capable(CAP_SYS_ADMIN) to create the trusted.* xattrs. Long-term, Al Viro wants to replace the xattr-based whiteouts with a true whiteout directory entry that can be shared by union mounts. In the meantime, we were wondering what are the downsides if we simply use user.* xattrs instead of trusted.*. The most glaring mis-behavior would be that whereas currently ID=$(id -u) sudo mkdir /tmp/x sudo touch /tmp/x/a sudo chown $ID /tmp/x/a rm /tmp/x/a fails, an unprivileged user might be able to work around that by manually setting the whiteout xattr. However, overlayfs explicitly prevents such writes to the overlayfs mounts, so the user would have to find direct access to the directory serving as the write layer to do so. So - Miklos, Andrew, would this seem like an ok thing to do for now, using user.overlay instead of trusted.overlay? Or are there other problems with this which we haven't considered? thanks, -serge
On Tue, Feb 11, 2014 at 04:38:09PM -0600, Serge Hallyn wrote: > (CC:ing Miklos for further insight; Miklos, for reference the original > email is: > https://lists.ubuntu.com/archives/kernel-team/2014-February/038811.html) > > Hi, > > with the applied patch we can start overlayfs-based containers as an > unprivileged user - however we can't delete files because we need > capable(CAP_SYS_ADMIN) to create the trusted.* xattrs. > > Long-term, Al Viro wants to replace the xattr-based whiteouts > with a true whiteout directory entry that can be shared by > union mounts. In the meantime, we were wondering what are the > downsides if we simply use user.* xattrs instead of trusted.*. > > The most glaring mis-behavior would be that whereas currently > > ID=$(id -u) > sudo mkdir /tmp/x > sudo touch /tmp/x/a > sudo chown $ID /tmp/x/a > rm /tmp/x/a > > fails, an unprivileged user might be able to work around that > by manually setting the whiteout xattr. However, overlayfs > explicitly prevents such writes to the overlayfs mounts, so the > user would have to find direct access to the directory serving > as the write layer to do so. > > So - Miklos, Andrew, would this seem like an ok thing to do > for now, using user.overlay instead of trusted.overlay? Or > are there other problems with this which we haven't considered? > > thanks, > -serge Just a quick note that we also discussed doing that only for the userns case, so overlayfs in the initial userns (mounted as real root) would still use "trusted." which would limit the scope of the problem to containers and also avoid some potential confusion with existing overlayfs overlays that'd be broken should we just change "trusted." for "user.". All this obviously isn't ideal and is more of a stop gap mesure until the longer term solution of not using extended attributes for that at all.
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");
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> --- fs/overlayfs/super.c | 1 + 1 file changed, 1 insertion(+)