[PATCH 1/1] RFC: Overlayfs: allow unprivileged mounts

[Stéphane Graber]

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.

-- 
Stéphane Graber
Ubuntu developer
http://www.canonical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20140211/29cc3e89/attachment.sig>