When overlayfs needs to perform internal operations which require
privileges the current user may not have, it does so by
selectively raising the required capabilities in the current set
of credentials. If the current process is in a user namespace
this doesn't always work, as operations such as setting
privileged xattrs often requires privileges in init_user_ns.

These operations really ought to be permitted, based on a couple
of facts:

 1. The vfs has already verified that the current process is
    allowed to perform the requested operation on the overlayfs
    super block, and overlayfs has verified that the operation is
    permitted in upperdir.

 2. The original mounter of the overlayfs super block was
    privileged enough to perform the internal overlayfs
    operations required to satisfy the user's request in
    upperdir.

On the other hand, if the filesystem is mounted from a user
namespace and then accessed in init_user_ns the credentials taken
will exceed those of the mounter. This could result in performing
operations that the user could not do otherwise, such as creating
files which are sxid for another user or group. Both of these
issues can be prevented by using the mounter's credentials when
performing privileged overlayfs-internal operations.

Add a new internal interface, ovl_prepare_creds(), which returns
a new set of credentials for performing privileged internal
operations that is identical to the mounter's creds. Use this
internal interface instead of using prepare_creds() and
selectively raising the needed capabilities.

BugLink: http://bugs.launchpad.net/bugs/1531747
BugLink: http://bugs.launchpad.net/bugs/1534961
BugLink: http://bugs.launchpad.net/bugs/1535150Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>