On 08/28/2018 11:42 AM, Amir Goldstein wrote:
On Tue, Aug 28, 2018 at 8:43 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote:
On Tue, Aug 28, 2018 at 7:53 PM Mark Salyzyn <salyzyn@xxxxxxxxxxx> wrote:
Assumption never checked, should fail if the mounter creds are not
sufficient.
Signed-off-by: Mark Salyzyn <salyzyn@xxxxxxxxxxx>
Cc: Miklos Szeredi <miklos@xxxxxxxxxx>
Cc: Jonathan Corbet <corbet@xxxxxxx>
Cc: Vivek Goyal <vgoyal@xxxxxxxxxx>
Cc: Eric W. Biederman <ebiederm@xxxxxxxxxxxx>
Cc: Amir Goldstein <amir73il@xxxxxxxxx>
Cc: Randy Dunlap <rdunlap@xxxxxxxxxxxxx>
Cc: Stephen Smalley <sds@xxxxxxxxxxxxx>
Cc: linux-unionfs@xxxxxxxxxxxxxxx
Cc: linux-doc@xxxxxxxxxxxxxxx
Cc: linux-kernel@xxxxxxxxxxxxxxx
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
