[1/1] RFC: 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>
---
 fs/overlayfs/super.c | 1 +
 1 file changed, 1 insertion(+)

(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.