Comment 22 for bug 1535150

On Wed, Feb 17, 2016 at 07:11:57AM -0000, J. R. Okajima wrote:
> The security bug hunter halfdog kindly invited me here.
>
> These 6 patches using the mounter's cred are interesting approach, but I have a question.
> - mount(2) requires CAP_SYS_ADMIN only. CAP_CHOWN is not necessary.
> - the internal copy-up requires CAP_CHOWN. CAP_DAC_OVERRIDE, CAP_FOWNER, CAP_FSETID, CAP_CHOWN, and CAP_MKNOD.

Yes, mount(2) requires CAP_SYS_ADMIN only. Any access to files and
directories in the mounted filesystem are subject to DAC checks on the
relevant inodes, see inode_permission(). This eventually results in
calling generic_permission(). You can see there that there are
capability checks for either CAP_DAC_OVERRIDE or CAP_DAC_READ_SEARCH,
depending on context, to allow operations which otherwise would not be
permitted by DAC.

Note that for overlayfs ovl_permission() gets called from
do_inode_permission(), which in turn checks permissions on the relevant
inode from the upper or lower mount.

With respect to CAP_CHOWN, this gets checked in inode_change_ok() when
changing inode attributes. You can see that ovl_setattr() calls this
without holding any elevated privileges.

> When the mounter doesn't have CAP_CHOWN and others, can a user open the
> file which is owned by another user?

Normal users will be subject to DAC (and MAC for that matter) when
attempting to open any file. As I explained above, a user with either
CAP_DAC_OVERRIDE or CAP_DAC_READ_SEARCH in the user namespace of the
mount namespace to which the mount belongs may not be subject to DAC in
many circumstances.

The cases where overlayfs takes on additional capabilities are after
DAC/MAC checks have completed. In essence these are taken for operations
done by the kernel in upperdir in order to satisfy the user request
which the vfs has already allowed in the overlayfs mount.