Messages in this thread | | | Subject | Re: [PATCH v5 2/3] overlayfs: check CAP_MKNOD before issuing vfs_whiteout | From | Mark Salyzyn <> | Date | Tue, 28 Aug 2018 11:51:55 -0700 |
| |
On 08/28/2018 11:42 AM, Amir Goldstein wrote: > On Tue, Aug 28, 2018 at 8:43 PM Amir Goldstein <amir73il@gmail.com> wrote: >> On Tue, Aug 28, 2018 at 7:53 PM Mark Salyzyn <salyzyn@android.com> wrote: >>> Assumption never checked, should fail if the mounter creds are not >>> sufficient. >>> >>> Signed-off-by: Mark Salyzyn <salyzyn@android.com> >>> Cc: Miklos Szeredi <miklos@szeredi.hu> >>> Cc: Jonathan Corbet <corbet@lwn.net> >>> Cc: Vivek Goyal <vgoyal@redhat.com> >>> Cc: Eric W. Biederman <ebiederm@xmission.com> >>> Cc: Amir Goldstein <amir73il@gmail.com> >>> Cc: Randy Dunlap <rdunlap@infradead.org> >>> Cc: Stephen Smalley <sds@tycho.nsa.gov> >>> Cc: linux-unionfs@vger.kernel.org >>> Cc: linux-doc@vger.kernel.org >>> Cc: linux-kernel@vger.kernel.org >>> >>> v5 >>> - dependency of "overlayfs: override_creds=off option bypass creator_cred" >>> --- >>> fs/overlayfs/overlayfs.h | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/fs/overlayfs/overlayfs.h b/fs/overlayfs/overlayfs.h >>> index 7538b9b56237..bf3a80157d42 100644 >>> --- a/fs/overlayfs/overlayfs.h >>> +++ b/fs/overlayfs/overlayfs.h >>> @@ -176,7 +176,7 @@ static inline int ovl_do_rename(struct inode *olddir, struct dentry *olddentry, >>> >>> static inline int ovl_do_whiteout(struct inode *dir, struct dentry *dentry) >>> { >>> - int err = vfs_whiteout(dir, dentry); >>> + int err = capable(CAP_MKNOD) ? vfs_whiteout(dir, dentry) : -EPERM; >> Should that be ns_capable()? Should the test go into vfs_whiteout()? >> I feel there is no convention at all. >> > Nevermind, I don't think creating a whiteout poses any risk, so don't think > we need to worry about CAP_MKNOD. > > Thanks, > Amir.
Ok, will discard from the set, we can address this later if it creates concern (as in, not a dependency to my proposed feature flag). So we feel that whiteout node in the writeable playground of workdir/upperdir is not in itself a security concern. Other (more dangerous) mknod will be checked against the caller's credentials coming in.
-- Mark
| |