Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp7420227imm; Tue, 28 Aug 2018 11:43:46 -0700 (PDT) X-Google-Smtp-Source: ANB0VdbSwTjAozatT1Hgru9Dm7WBp1IpxZNiL7cGRJ0nAtsYDXBC0KswUuQ+qqrOuar4H8vXL7rZ X-Received: by 2002:a63:f80a:: with SMTP id n10-v6mr2601512pgh.82.1535481826127; Tue, 28 Aug 2018 11:43:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535481826; cv=none; d=google.com; s=arc-20160816; b=bJNaRW0MsZp3iVgAVWA+iTU0+eYyKccH1v5KRSToUSlZW0bCDFCQvRzWMphP5e7p+Q NSJwUyrciKkJOZhUWHNqOCJ2dbwS5Nhf0rkoHv3qodmeQDPCENpgydDgB0OAXRYUo22n Q3qY1AGFjY0BdDqmPUE7Bhe5Fmr8bq4la/5OAxyab9o93fL9JmPHGbLNlboYbXpCzJ+f V2vQgZ+AJOHuJLBnynJFO7upAQrvGSmypJk2pQLxcHZ1D0ODbhfjzaYwoawdNRgxN0Vv EOX1da0jAarIpdhv1249p+DGa3fcMQWfUmXd2gk1mioeXg0CeQUwZ93Wx+xI1MF555JX TC1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=72jb2gGwS7x6y4GgUk8P2e2+GcHI7zxIQttp7hAKHtk=; b=VGgnZUsdImyftww+yOUvFB5g25OynyUSJtbH+LxcozCN5hmM2g04CHX9d0YQ+eetlc 39/u+10i3QAJly36TjbTQIm/a3fuEifJZlokOkCCl2jwPEGCiy3sPNAL13YH6X9Ld1/7 CThrDzcimxmBXwhoGcL/4Uz9zbrs9eyJTUfpHcN7uTSALWV3pdkgD7qnERtiXLNrq6pp ya0rYakOUNzDSv441JBSXq+vkiBHYDwmYjjSh7xFZ00yvy60cQUtduSYTtfHfwaQEIOR B06JcblDdy9/GBKqTWnvCvctFZ41n5vSyvkMuFkETGh82dA3R5EgFLIqnGOM5Cfmg3hS xW4Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=QxwQ4Xo8; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g27-v6si1489174pgm.208.2018.08.28.11.43.30; Tue, 28 Aug 2018 11:43:46 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=QxwQ4Xo8; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727271AbeH1WfQ (ORCPT + 99 others); Tue, 28 Aug 2018 18:35:16 -0400 Received: from mail-yb0-f194.google.com ([209.85.213.194]:35876 "EHLO mail-yb0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726833AbeH1WfQ (ORCPT ); Tue, 28 Aug 2018 18:35:16 -0400 Received: by mail-yb0-f194.google.com with SMTP id d34-v6so1003259yba.3; Tue, 28 Aug 2018 11:42:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=72jb2gGwS7x6y4GgUk8P2e2+GcHI7zxIQttp7hAKHtk=; b=QxwQ4Xo8sQePdz+JtcB8uuwNnWdoV6TOxnHmxG60lJ8dsGYMY7zHxPrqrKK0NL6KWb SrSrNJM28xkt4k2A5O+ptbC8pSJvbnqBYsJgLFDyNGBH82xr9yGHAeDokYCd3zd46ii0 Mff13u/MjYcgJn5Ws6QgYrhVp3rfR5PJMsvFa2nWVooKhQMDHhp5X4btWxhYwS87n0dQ zMXvcJsCUwtNA03cWBAnRAJDpD4wrZNUgsESJiwYLVui5ztn4vdjh+r7fr1UYIY3l3po bAK5MVRcX22XN4FYI/JeZqmVHiQ3Qvlg4bCNXN/HxyZnRScE2DDtLqxI9KDk+00a3c+q NCyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=72jb2gGwS7x6y4GgUk8P2e2+GcHI7zxIQttp7hAKHtk=; b=EMckwudgZLPejGQ9PFYtll2+i64EDyQjY+Ow1gHNcRDSne2LOahjWY1gmxVzAYOQm3 6vAjMOq4NX5K5hihZZE02EXdRUr0HZPhbBZnefOHPTBwXyTZXpV1FSMS9H4zSO0J9twT CNVDRdXa0LgUPLYLNtBemU6mGA5Q3xGhYO3V/g/pjHyPEMECQnhFgiXDUQGMkbKJ/SB9 26gUfylb9v/il5cJb0yQPiU5DCImuOeYSC1W6y5kQfPluxvo8fUsV8efNtbAbhc4qyDz TSkXdnuT3bb9+/avTWO0LyaVs80RusUBbdxdnrkuif7HPJ7A16s0FdTqHLoREHioIDJ9 I33Q== X-Gm-Message-State: APzg51D87h+rdGLOWU4D32AO1EsztemwrzpLdw7ZWFUQjWecw9LMgR/P boUuOqkabQ+plfUVHLbaS52ahNpYQY/COM556Hk= X-Received: by 2002:a25:1a85:: with SMTP id a127-v6mr1555786yba.507.1535481740341; Tue, 28 Aug 2018 11:42:20 -0700 (PDT) MIME-Version: 1.0 References: <20180828165319.211563-1-salyzyn@android.com> In-Reply-To: From: Amir Goldstein Date: Tue, 28 Aug 2018 21:42:09 +0300 Message-ID: Subject: Re: [PATCH v5 2/3] overlayfs: check CAP_MKNOD before issuing vfs_whiteout To: Mark Salyzyn Cc: linux-kernel , Miklos Szeredi , Jonathan Corbet , Vivek Goyal , "Eric W. Biederman" , Randy Dunlap , Stephen Smalley , overlayfs , linux-doc@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 28, 2018 at 8:43 PM Amir Goldstein wrote: > > On Tue, Aug 28, 2018 at 7:53 PM Mark Salyzyn wrote: > > > > Assumption never checked, should fail if the mounter creds are not > > sufficient. > > > > Signed-off-by: Mark Salyzyn > > Cc: Miklos Szeredi > > Cc: Jonathan Corbet > > Cc: Vivek Goyal > > Cc: Eric W. Biederman > > Cc: Amir Goldstein > > Cc: Randy Dunlap > > Cc: Stephen Smalley > > 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.