Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp153138pxf; Wed, 24 Mar 2021 01:28:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwDM2NkuOLD6x4jz2gaikzFSmCMdbfasOQN7dImBfLMk4ZVJjO/yzJ1OSCT3rZuU51uOzXo X-Received: by 2002:a17:907:1614:: with SMTP id hb20mr2411741ejc.77.1616574522379; Wed, 24 Mar 2021 01:28:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616574522; cv=none; d=google.com; s=arc-20160816; b=lKROnWGRFniVSehkFV2JXOr+qP+qyAYWDil1Z/yIl/7Z2hkUO4jjUqs5iPfsl0KOi5 paIRL501Z7s1VgVMXsaJyY+2omra/iFlZIkSXbdWKXAX14uUSMWzoyXwiuiAv5zCOk2K AajF729bTOvbj3wiIIAA2xVQXGnbU7i2EaeQka9DhldM/zt14I835PQiWtXQaC3qGxo7 9ej/kXeJJeR4k9k4WU6oC7IDXiHJvMoIlKKxENQsAmlUgkO6BchRmG5u4JZSF9nfYuEA ICMJdTC1uxNcv/fsgHXrvyLGrw6jDXjau1Bzw6wv34lge36lR+q5oOJ57Es+J6VdawKR I8IA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=1Cr93mb6JnRs4arNME88BnQuOUnzIS6N9+cha3N56us=; b=z40qfH0FB2kzzMzVTTfLUtuB+xnTfLCfMJ3vHNc2CA76iyToncWakS/r0ebcevoCiD mFhFac/WZ6gEXfDFFdF6jwmb/HGCYciV+J1jrYNyXJCdbGQ0qD1sUQOBbZunGoEDzMal eyjq7EWmWym18lZiqg6fnWI4TmJ0XeKAwwkWjqN6FRnK9wt63DsofMs0IeifDnwO/pHx rdaeUpFgLr7PlWCVH7jktcKn+dKSTdIs4hdzxjBiHwOD4PpseMJfg9N5ApsSKc2cLdSh ptpK0XmHjNrea3Tt7F/hGo7SGBtDRGoYQ+3y3GeNbDFFkwVhp0gBcPcCe8Jb/rNBKYxN wHcg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=RLhYNVny; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j22si1304636ejb.269.2021.03.24.01.28.19; Wed, 24 Mar 2021 01:28:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=RLhYNVny; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233801AbhCWWvT (ORCPT + 99 others); Tue, 23 Mar 2021 18:51:19 -0400 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:40886 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233878AbhCWWuz (ORCPT ); Tue, 23 Mar 2021 18:50:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1616539854; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1Cr93mb6JnRs4arNME88BnQuOUnzIS6N9+cha3N56us=; b=RLhYNVnyZSVpRmpSJJE5r+m1tF2jsbEJklfF7jjZgPxlOt/JGFHg/GEyU1vlfYOFrhaWGw n7M4/hY+vrZ005/l2X4zJfgzQ6p9o4EX3UKG5wlXrEZhFHubqv3qhSN1CtyaGLR/dld2J4 JR1Wktgns5Psh75UPMJ54G72oqCiUn4= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-530-XovzKeluNreOh25xzxZyQw-1; Tue, 23 Mar 2021 18:50:53 -0400 X-MC-Unique: XovzKeluNreOh25xzxZyQw-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id AB7065B361; Tue, 23 Mar 2021 22:50:51 +0000 (UTC) Received: from horse.redhat.com (ovpn-116-103.rdu2.redhat.com [10.10.116.103]) by smtp.corp.redhat.com (Postfix) with ESMTP id AA26B5C1C5; Tue, 23 Mar 2021 22:50:46 +0000 (UTC) Received: by horse.redhat.com (Postfix, from userid 10451) id 10A4F220BCF; Tue, 23 Mar 2021 18:50:46 -0400 (EDT) Date: Tue, 23 Mar 2021 18:50:46 -0400 From: Vivek Goyal To: Christian Brauner Cc: Christian Brauner , Andreas =?iso-8859-1?Q?Gr=FCnbacher?= , Linux FS-devel Mailing List , Linux Kernel Mailing List , virtio-fs@redhat.com, Miklos Szeredi , lhenriques@suse.de, dgilbert@redhat.com, Seth Forshee , Jan Kara , Andreas Gruenbacher , Alexander Viro Subject: Re: [PATCH 1/3] posic_acl: Add a helper determine if SGID should be cleared Message-ID: <20210323225046.GH483930@redhat.com> References: <20210319195547.427371-1-vgoyal@redhat.com> <20210319195547.427371-2-vgoyal@redhat.com> <20210320100322.ox5gzgauo7iqf2fv@gmail.com> <20210322170111.GE446288@redhat.com> <20210323093233.iyl4k6x432ytb72c@wittgenstein> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210323093233.iyl4k6x432ytb72c@wittgenstein> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 23, 2021 at 10:32:33AM +0100, Christian Brauner wrote: > On Mon, Mar 22, 2021 at 01:01:11PM -0400, Vivek Goyal wrote: > > On Sat, Mar 20, 2021 at 11:03:22AM +0100, Christian Brauner wrote: > > > On Fri, Mar 19, 2021 at 11:42:48PM +0100, Andreas Gr?nbacher wrote: > > > > Hi, > > > > > > > > Am Fr., 19. M?rz 2021 um 20:58 Uhr schrieb Vivek Goyal : > > > > > posix_acl_update_mode() determines what's the equivalent mode and if SGID > > > > > needs to be cleared or not. I need to make use of this code in fuse > > > > > as well. Fuse will send this information to virtiofs file server and > > > > > file server will take care of clearing SGID if it needs to be done. > > > > > > > > > > Hence move this code in a separate helper so that more than one place > > > > > can call into it. > > > > > > > > > > Cc: Jan Kara > > > > > Cc: Andreas Gruenbacher > > > > > Cc: Alexander Viro > > > > > Signed-off-by: Vivek Goyal > > > > > --- > > > > > fs/posix_acl.c | 3 +-- > > > > > include/linux/posix_acl.h | 11 +++++++++++ > > > > > 2 files changed, 12 insertions(+), 2 deletions(-) > > > > > > > > > > diff --git a/fs/posix_acl.c b/fs/posix_acl.c > > > > > index f3309a7edb49..2d62494c4a5b 100644 > > > > > --- a/fs/posix_acl.c > > > > > +++ b/fs/posix_acl.c > > > > > @@ -684,8 +684,7 @@ int posix_acl_update_mode(struct user_namespace *mnt_userns, > > > > > return error; > > > > > if (error == 0) > > > > > *acl = NULL; > > > > > - if (!in_group_p(i_gid_into_mnt(mnt_userns, inode)) && > > > > > - !capable_wrt_inode_uidgid(mnt_userns, inode, CAP_FSETID)) > > > > > + if (posix_acl_mode_clear_sgid(mnt_userns, inode)) > > > > > mode &= ~S_ISGID; > > > > > *mode_p = mode; > > > > > return 0; > > > > > diff --git a/include/linux/posix_acl.h b/include/linux/posix_acl.h > > > > > index 307094ebb88c..073c5e546de3 100644 > > > > > --- a/include/linux/posix_acl.h > > > > > +++ b/include/linux/posix_acl.h > > > > > @@ -59,6 +59,17 @@ posix_acl_release(struct posix_acl *acl) > > > > > } > > > > > > > > > > > > > > > +static inline bool > > > > > +posix_acl_mode_clear_sgid(struct user_namespace *mnt_userns, > > > > > + struct inode *inode) > > > > > +{ > > > > > + if (!in_group_p(i_gid_into_mnt(mnt_userns, inode)) && > > > > > + !capable_wrt_inode_uidgid(mnt_userns, inode, CAP_FSETID)) > > > > > + return true; > > > > > + > > > > > + return false; > > > > > > > > That's just > > > > > > > > return !in_group_p(i_gid_into_mnt(mnt_userns, inode)) && > > > > !capable_wrt_inode_uidgid(mnt_userns, inode, CAP_FSETID); > > > > > > > > The same pattern we have in posix_acl_update_mode also exists in > > > > setattr_copy and inode_init_owner, and almost the same pattern exists > > > > in setattr_prepare, so can this be cleaned up as well? The function > > > > also isn't POSIX ACL specific, so the function name is misleading. > > > > > > Good idea but that should probably be spun into a separate patchset that > > > only touches the vfs parts. > > > > IIUC, suggestion is that I should write a VFS helper (and not posix > > acl helper) and use that helper at other places too in the code. > > If there are other callers outside of acls (which should be iirc) then > yes. > > > > > I will do that and post in a separate patch series. > > Yeah, I think that makes more sense to have this be a separate change > instead of putting it together with the fuse change if it touches more > than one place. I do see that there are few places where this pattern is used and atleast some of them should be straight forward conversion. I will follow this up in separate patch series. I suspect that this might take little bit of back and forth, so will follow with fuse changes in parallel and open code there. Once this series gets merged will send another patch for fuse. Thanks Vivek