From patchwork Fri May 20 16:10:34 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yang Xu X-Patchwork-Id: 574560 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 902E7C433F5 for ; Fri, 20 May 2022 15:10:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350622AbiETPK1 (ORCPT ); Fri, 20 May 2022 11:10:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59214 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244681AbiETPKX (ORCPT ); Fri, 20 May 2022 11:10:23 -0400 Received: from mail1.bemta34.messagelabs.com (mail1.bemta34.messagelabs.com [195.245.231.1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 81657170657; Fri, 20 May 2022 08:10:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fujitsu.com; s=170520fj; t=1653059420; i=@fujitsu.com; bh=e8B5juuhS5toG5hw6zygxw/VPuvjMx9f/RS70eZ4JIA=; h=From:To:CC:Subject:Date:Message-ID:MIME-Version:Content-Type; b=WElLPHirCQ6ngd84DCKP3el7h+G1GXwPAhd+2s+qMNcjnQ9u/a4C/UNcv6wv6xvFZ FLy3hC48lZaowJGrnjZ+HFk9/Q3jSMCsnKTLHAIWM+5P25un+wDllF4qv7Yf23W28J +CC2weXtVrKXxYayda25+wYNBbfogcJMXgyXSn72mfXqHTChNoX+DCGHXfldpMf9qQ SHyqKUUXU4FmHTaOOTMaQBQnZTSxENVY/yCyMNXMCN4zottHY+OMnAHKen6XlyGAkG IO7m45cfY5iLx/gGvb9HYH3wXLVAEufb0iIHnm+stSN3eQHzgh+T2sRGZeQ+zN4sgj Lq4JFvMQ1//rQ== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGIsWRWlGSWpSXmKPExsViZ8MxSTd6fXu SwcpnXBavD39itPhwcxKTxZZj9xgtLj/hs/i5bBW7xZ69J1kszv89zmrx+8ccNgcOj1OLJDw2 r9Dy2LSqk83j8yY5j01P3jIFsEaxZuYl5VcksGbcv/6TpeCUbMXMJ/eZGxh/SnQxcnEICWxhl Pj97zUjhLOASWLts9+sEM4eRonmm4tYuhg5OdgENCWedS5gBrFFBBwlXrTPAIszC2xmlFj2OB zEFhawkDh3YhkbiM0ioCqx5/cdRhCbV8BD4tCPZiYQW0JAQWLKw/fMEHFBiZMzn0DNkZA4+OI FM0SNosSljm+MEHaFxOvDl6DiahJXz21insDIPwtJ+ywk7QsYmVYxWiUVZaZnlOQmZuboGhoY 6BoamuoaW+paGOklVukm6qWW6panFpfoArnlxXqpxcV6xZW5yTkpenmpJZsYgcGfUqwetIPx2 4qfeocYJTmYlER5S1e0JwnxJeWnVGYkFmfEF5XmpBYfYpTh4FCS4M1ZA5QTLEpNT61Iy8wBRi JMWoKDR0mEV34tUJq3uCAxtzgzHSJ1ilFRSpzXbh1QQgAkkVGaB9cGi/5LjLJSwryMDAwMQjw FqUW5mSWo8q8YxTkYlYR5VVcDTeHJzCuBm/4KaDET0OJbyq0gi0sSEVJSDUzFTxJcdT1CIvc+ 57Au+q88Q55RaMelRb90hYofex68dyZK+kNncRL3qdZlbZP745RPl99VyZstw5oW99Pz5PodH j0HWH5p7r139PXx7t0bWxrZZ88JEopaE+cxzXK/it/S3zMX6waeXtHg8khydaRf7WzhAt+yx6 v87undO/PvqkmaQGC1Qb1nLPvuaaJKvA/Y+f4zlOxb1n7jrlC3yxvFj7tWhx2PKVYsvlxm/YY h4dEtJp477zWS/+008slb7DN1lumWaZ1alhz5DSqHwn72LxG5OSVg82uXu9Zi03TdJd4/iWaZ bLTYhO2PAkNQaesVXSaV741PrDnPa2kmbNyxyPFoT9BqofXpS42bC5VYijMSDbWYi4oTAV6i+ 5Z5AwAA X-Env-Sender: xuyang2018.jy@fujitsu.com X-Msg-Ref: server-7.tower-571.messagelabs.com!1653059418!68365!1 X-Originating-IP: [62.60.8.146] X-SYMC-ESS-Client-Auth: outbound-route-from=pass X-StarScan-Received: X-StarScan-Version: 9.86.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 462 invoked from network); 20 May 2022 15:10:19 -0000 Received: from unknown (HELO n03ukasimr02.n03.fujitsu.local) (62.60.8.146) by server-7.tower-571.messagelabs.com with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 20 May 2022 15:10:19 -0000 Received: from n03ukasimr02.n03.fujitsu.local (localhost [127.0.0.1]) by n03ukasimr02.n03.fujitsu.local (Postfix) with ESMTP id B6A63100359; Fri, 20 May 2022 16:10:18 +0100 (BST) Received: from R01UKEXCASM126.r01.fujitsu.local (unknown [10.183.43.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by n03ukasimr02.n03.fujitsu.local (Postfix) with ESMTPS id A8F9D1000FB; Fri, 20 May 2022 16:10:18 +0100 (BST) Received: from localhost.localdomain (10.167.220.84) by R01UKEXCASM126.r01.fujitsu.local (10.183.43.178) with Microsoft SMTP Server (TLS) id 15.0.1497.32; Fri, 20 May 2022 16:09:55 +0100 From: Yang Xu To: , CC: , , , , , , Yang Xu Subject: [PATCH v9 1/4] fs: add mode_strip_sgid() helper Date: Sat, 21 May 2022 00:10:34 +0800 Message-ID: <1653063037-2461-1-git-send-email-xuyang2018.jy@fujitsu.com> X-Mailer: git-send-email 1.8.3.1 MIME-Version: 1.0 X-Originating-IP: [10.167.220.84] X-ClientProxiedBy: G08CNEXCHPEKD08.g08.fujitsu.local (10.167.33.83) To R01UKEXCASM126.r01.fujitsu.local (10.183.43.178) X-Virus-Scanned: ClamAV using ClamSMTP Precedence: bulk List-ID: X-Mailing-List: ceph-devel@vger.kernel.org Add a dedicated helper to handle the setgid bit when creating a new file in a setgid directory. This is a preparatory patch for moving setgid stripping into the vfs. The patch contains no functional changes. Currently the setgid stripping logic is open-coded directly in inode_init_owner() and the individual filesystems are responsible for handling setgid inheritance. Since this has proven to be brittle as evidenced by old issues we uncovered over the last months (see [1] to [3] below) we will try to move this logic into the vfs. Link: e014f37db1a2 ("xfs: use setattr_copy to set vfs inode attributes") [1] Link: 01ea173e103e ("xfs: fix up non-directory creation in SGID directories") [2] Link: fd84bfdddd16 ("ceph: fix up non-directory creation in SGID directories") [3] Reviewed-by: Darrick J. Wong Reviewed-by: Christian Brauner (Microsoft) Reviewed-and-Tested-by: Jeff Layton Signed-off-by: Yang Xu --- v8->v9: 1.move if orders in mode_strip_sgid helper 2.xfstests testcase url https://patchwork.kernel.org/project/fstests/list/?series=643643 fs/inode.c | 37 +++++++++++++++++++++++++++++++++---- include/linux/fs.h | 2 ++ 2 files changed, 35 insertions(+), 4 deletions(-) diff --git a/fs/inode.c b/fs/inode.c index 9d9b422504d1..37bd85981d38 100644 --- a/fs/inode.c +++ b/fs/inode.c @@ -2246,10 +2246,8 @@ void inode_init_owner(struct user_namespace *mnt_userns, struct inode *inode, /* Directories are special, and always inherit S_ISGID */ if (S_ISDIR(mode)) mode |= S_ISGID; - else if ((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP) && - !in_group_p(i_gid_into_mnt(mnt_userns, dir)) && - !capable_wrt_inode_uidgid(mnt_userns, dir, CAP_FSETID)) - mode &= ~S_ISGID; + else + mode = mode_strip_sgid(mnt_userns, dir, mode); } else inode_fsgid_set(inode, mnt_userns); inode->i_mode = mode; @@ -2405,3 +2403,34 @@ struct timespec64 current_time(struct inode *inode) return timestamp_truncate(now, inode); } EXPORT_SYMBOL(current_time); + +/** + * mode_strip_sgid - handle the sgid bit for non-directories + * @mnt_userns: User namespace of the mount the inode was created from + * @dir: parent directory inode + * @mode: mode of the file to be created in @dir + * + * If the @mode of the new file has both the S_ISGID and S_IXGRP bit + * raised and @dir has the S_ISGID bit raised ensure that the caller is + * either in the group of the parent directory or they have CAP_FSETID + * in their user namespace and are privileged over the parent directory. + * In all other cases, strip the S_ISGID bit from @mode. + * + * Return: the new mode to use for the file + */ +umode_t mode_strip_sgid(struct user_namespace *mnt_userns, + const struct inode *dir, umode_t mode) +{ + if ((mode & (S_ISGID | S_IXGRP)) != (S_ISGID | S_IXGRP)) + return mode; + if (S_ISDIR(mode) || !dir || !(dir->i_mode & S_ISGID)) + return mode; + if (in_group_p(i_gid_into_mnt(mnt_userns, dir))) + return mode; + if (capable_wrt_inode_uidgid(mnt_userns, dir, CAP_FSETID)) + return mode; + + mode &= ~S_ISGID; + return mode; +} +EXPORT_SYMBOL(mode_strip_sgid); diff --git a/include/linux/fs.h b/include/linux/fs.h index bbde95387a23..3bccb7ba44a5 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -1897,6 +1897,8 @@ extern long compat_ptr_ioctl(struct file *file, unsigned int cmd, void inode_init_owner(struct user_namespace *mnt_userns, struct inode *inode, const struct inode *dir, umode_t mode); extern bool may_open_dev(const struct path *path); +umode_t mode_strip_sgid(struct user_namespace *mnt_userns, + const struct inode *dir, umode_t mode); /* * This is the "filldir" function type, used by readdir() to let From patchwork Fri May 20 16:10:35 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yang Xu X-Patchwork-Id: 575438 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 27890C4332F for ; Fri, 20 May 2022 15:10:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343812AbiETPKb (ORCPT ); Fri, 20 May 2022 11:10:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59228 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241781AbiETPKY (ORCPT ); Fri, 20 May 2022 11:10:24 -0400 Received: from mail1.bemta36.messagelabs.com (mail1.bemta36.messagelabs.com [85.158.142.113]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ED58117706D; Fri, 20 May 2022 08:10:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fujitsu.com; s=170520fj; t=1653059420; i=@fujitsu.com; bh=lKY9yswoHVpDbGbLhaeMQH9R5j0Sb+KVNk4RxWU9pOY=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Re2la0jQBih2kCHYP7KntPHO6JK/c4nOGBslI7Whb21ofNHmcNHpJv9vB9bmhl+wB xosG8cbBOHSfzVZSy5tvvOJameMsUTqmA7yhgwYpgBDuwt28ROQQ7nyTNQvKr7Vb28 0dvCekYTXLXIFIbs4+kKhuQkClf93MJbqrI/rVOH2uWvCEQKl4bK3qUS9mEu2FF18J JAJn0G3iR2yrxtmV4UplUV6HlS/xpS9Es39sWaiZXVdONqENwfzn0JEiMZkOw3FTvf B22OwFVg572dNIG2+WS8f3tPz/O/SLsOGgP5Q/wVNYp00waG4rRANiwIRegV9YAXWl Ker5Y0TSpDT2Q== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjleJIrShJLcpLzFFi42Kxs+GYpBu9vj3 J4He7kMXrw58YLT7cnMRkseXYPUaLy0/4LH4uW8VusWfvSRaLBRsfMVqc/3uc1eL3jzlsDpwe pxZJeGxeoeWxaVUnm8fnTXIem568ZQpgjWLNzEvKr0hgzXj17hZrwWvOivlHX7I2MO7l6GLk4 hAS2MIo8ebtBsYuRk4gZwGTxLkVoRCJPYwSWx51sYIk2AQ0JZ51LmAGsUUEHCVetM9gASliFj jLKNExYxE7SEJYwEli05oFYA0sAqoSbz79YAGxeQU8JBbN2QzWLCGgIDHl4Xswm1PAU2LB9W6 2LkYOoG0eEksWyECUC0qcnPkErJVZQELi4IsXUK2KEpc6vjFC2BUSrw9fgoqrSVw9t4l5AqPg LCTts5C0L2BkWsVol1SUmZ5RkpuYmaNraGCga2hoqmtuqGtobKyXWKWbqJdaqpucmldSlAiU1 kssL9ZLLS7WK67MTc5J0ctLLdnECIyelGL31h2Ml/t+6h1ilORgUhLlLV3RniTEl5SfUpmRWJ wRX1Sak1p8iFGGg0NJgjdnDVBOsCg1PbUiLTMHGMkwaQkOHiURXvm1QGne4oLE3OLMdIjUKUZ FKXFeu3VACQGQREZpHlwbLHlcYpSVEuZlZGBgEOIpSC3KzSxBlX/FKM7BqCTMq7oaaApPZl4J 3PRXQIuZgBbfUm4FWVySiJCSamA6/8/UJGpayuH181vN1z9N8zQIitI5+jOaaZ7YS7lJQgbOE ocOvk9Pjjl8Mexptsbt5sokdoYNJ3Me2J5U1zLwtk1a2cbqNffZ50Un3HNZfy6YYK7gdWRDVs rCOVNUN5z9OE/9ybHJK+c/3PBhv5nohNQvi+d2stzf7fempbZjTQEbt2ebgJF4wqFLFkfDJiu s2rfhVtIRw4Li1EfaD/8lye6eONPBWOjhSvuHgZsnPP60hu1Ovu0jg6L9BX7ZMxX23Nxt7HJX oEVw1R2L+MfM/RvX1uXlvK88EhL67wxLzL9u1U/MZlEnluttSV27j2G557G3Zx9wPKvMztrb8 Eck8L7Asxsal88klblMrErZpMRSnJFoqMVcVJwIAGaXw+2ZAwAA X-Env-Sender: xuyang2018.jy@fujitsu.com X-Msg-Ref: server-3.tower-532.messagelabs.com!1653059418!259556!1 X-Originating-IP: [62.60.8.146] X-SYMC-ESS-Client-Auth: outbound-route-from=pass X-StarScan-Received: X-StarScan-Version: 9.86.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6613 invoked from network); 20 May 2022 15:10:19 -0000 Received: from unknown (HELO n03ukasimr02.n03.fujitsu.local) (62.60.8.146) by server-3.tower-532.messagelabs.com with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 20 May 2022 15:10:19 -0000 Received: from n03ukasimr02.n03.fujitsu.local (localhost [127.0.0.1]) by n03ukasimr02.n03.fujitsu.local (Postfix) with ESMTP id BA175100445; Fri, 20 May 2022 16:10:18 +0100 (BST) Received: from R01UKEXCASM126.r01.fujitsu.local (unknown [10.183.43.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by n03ukasimr02.n03.fujitsu.local (Postfix) with ESMTPS id AD180100331; Fri, 20 May 2022 16:10:18 +0100 (BST) Received: from localhost.localdomain (10.167.220.84) by R01UKEXCASM126.r01.fujitsu.local (10.183.43.178) with Microsoft SMTP Server (TLS) id 15.0.1497.32; Fri, 20 May 2022 16:10:07 +0100 From: Yang Xu To: , CC: , , , , , , Yang Xu , Subject: [PATCH v9 2/4] fs: Add missing umask strip in vfs_tmpfile Date: Sat, 21 May 2022 00:10:35 +0800 Message-ID: <1653063037-2461-2-git-send-email-xuyang2018.jy@fujitsu.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1653063037-2461-1-git-send-email-xuyang2018.jy@fujitsu.com> References: <1653063037-2461-1-git-send-email-xuyang2018.jy@fujitsu.com> MIME-Version: 1.0 X-Originating-IP: [10.167.220.84] X-ClientProxiedBy: G08CNEXCHPEKD08.g08.fujitsu.local (10.167.33.83) To R01UKEXCASM126.r01.fujitsu.local (10.183.43.178) X-Virus-Scanned: ClamAV using ClamSMTP Precedence: bulk List-ID: X-Mailing-List: ceph-devel@vger.kernel.org All creation paths except for O_TMPFILE handle umask in the vfs directly if the filesystem doesn't support or enable POSIX ACLs. If the filesystem does then umask handling is deferred until posix_acl_create(). Because, O_TMPFILE misses umask handling in the vfs it will not honor umask settings. Fix this by adding the missing umask handling. Fixes: 60545d0d4610 ("[O_TMPFILE] it's still short a few helpers, but infrastructure should be OK now...") Cc: # 4.19+ Reported-by: Christian Brauner (Microsoft) Acked-by: Christian Brauner (Microsoft) Reviewed-by: Darrick J. Wong Reviewed-and-Tested-by: Jeff Layton Signed-off-by: Yang Xu --- fs/namei.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/namei.c b/fs/namei.c index 509657fdf4f5..73646e28fae0 100644 --- a/fs/namei.c +++ b/fs/namei.c @@ -3521,6 +3521,8 @@ struct dentry *vfs_tmpfile(struct user_namespace *mnt_userns, child = d_alloc(dentry, &slash_name); if (unlikely(!child)) goto out_err; + if (!IS_POSIXACL(dir)) + mode &= ~current_umask(); error = dir->i_op->tmpfile(mnt_userns, dir, child, mode); if (error) goto out_err; From patchwork Fri May 20 16:10:36 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yang Xu X-Patchwork-Id: 574559 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2EAC6C433F5 for ; Fri, 20 May 2022 15:11:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350660AbiETPLR (ORCPT ); Fri, 20 May 2022 11:11:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60594 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350682AbiETPLF (ORCPT ); Fri, 20 May 2022 11:11:05 -0400 Received: from mail3.bemta32.messagelabs.com (mail3.bemta32.messagelabs.com [195.245.230.82]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C0CFD220CC; Fri, 20 May 2022 08:10:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fujitsu.com; s=170520fj; t=1653059456; i=@fujitsu.com; bh=SPVEzIGvEb/dweQfjLghmAEZulLfpto4xrkT99RTG9Y=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=OkLKuzz2CkjcvpU8JxZmpU9zrsGHQvwIzlUltUJZ+FOPHtEx4u/J5wYq5/LDTA/uC 8vpdzwj2cU5/WIsgw/dEgyw+AnpZipUPIKDFgNa0qWtDtTPpvPQo4T/g1MhAwL86HK MGX2B5faNgxCpswMlwIPVXakZ++88bo0tvIGsFamzPRZkEA/B7XIG4c4zDzWVHChXm RB5y1PWeMvNu0dQnJ9yl5pTTbTUkNjyqPecas0Epg6R3HTFtkaolxzL6J6Jw/D7FkA rHLABm7LLly2G+ipSy1rOA0NSUfDLNXrKIRsG+Y1KuT9iUpfrjzc0aei+S78sN+/dz r6+h/H0K0k0tw== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnleJIrShJLcpLzFFi42Kxs+FI0i1d355 kMG21pMXrw58YLT7cnMRkseXYPUaLy0/4LH4uW8VusWfvSRaL83+Ps1r8/jGHzYHD49QiCY/N K7Q8Nq3qZPP4vEnOY9OTt0wBrFGsmXlJ+RUJrBkH13xlKZieWfHx0AXWBsaeiC5GLg4hgY2ME o9vf2eHcOYySVyffpQVwtnDKPFj1QGWLkZODjYBTYlnnQuYQWwRAUeJF+0zwOLMApsZJZY9Dg exhQXsJd58f8IOYrMIqEosfHKdEcTmFfCQaPj9mhXElhBQkJjy8D3YHE4BT4kF17vZuhg5gJZ 5SCxZIANRLihxcuYTqPESEgdfvGCGaFWUuNTxjRHCrpB4ffgSVFxN4uq5TcwTGAVnIWmfhaR9 ASPTKkarpKLM9IyS3MTMHF1DAwNdQ0NTXSBpZKyXWKWbqJdaqlueWlyia6iXWF6sl1pcrFdcm Zuck6KXl1qyiREYKynFDNU7GP/3/tQ7xCjJwaQkylu6oj1JiC8pP6UyI7E4I76oNCe1+BCjDA eHkgRvzhqgnGBRanpqRVpmDjBuYdISHDxKIrzya4HSvMUFibnFmekQqVOMxhxrGw7sZeZ4+vz EXmYhlrz8vFQpcV67dUClAiClGaV5cINg6eQSo6yUMC8jAwODEE9BalFuZgmq/CtGcQ5GJWFe 1dVAU3gy80rg9r0COoUJ6JRbyq0gp5QkIqSkGpgstA9GT7iUk77g2NG2XVf4NV++EL/D8/nUs o19LhHZi++qXvXg2sf/9+Ia1YLj/ZY2u4w/cs8u2mgywVLJP/F1yLPMfcXCQcd1lI/E/uazrx H+vOdjUTkj25aj2Q17805M1jp08fwbu2lbavgVK9q55JYuXKbSlcEy+15jb9rFFWftAqpO90X Zqs+M+hqQsObE/U0/602t9hy6vDctXI1N4QvnLZ430992na4ryEhqvnQyTCze/zDrlSm9uw9e 9XBN9FBWkj9ZaCDv3lC1RGvWhb1blsYbbPrp/vFZqvfqNx9DbJM3zbM+l+uqeWCdqPvu+vtW3 0yZQye4P+hTDVDYGFd/5N1jKR350j7muzVKLMUZiYZazEXFiQDxFbIDogMAAA== X-Env-Sender: xuyang2018.jy@fujitsu.com X-Msg-Ref: server-9.tower-585.messagelabs.com!1653059445!164098!1 X-Originating-IP: [62.60.8.98] X-SYMC-ESS-Client-Auth: outbound-route-from=pass X-StarScan-Received: X-StarScan-Version: 9.86.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10553 invoked from network); 20 May 2022 15:10:45 -0000 Received: from unknown (HELO n03ukasimr03.n03.fujitsu.local) (62.60.8.98) by server-9.tower-585.messagelabs.com with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 20 May 2022 15:10:45 -0000 Received: from n03ukasimr03.n03.fujitsu.local (localhost [127.0.0.1]) by n03ukasimr03.n03.fujitsu.local (Postfix) with ESMTP id D8AB4B5E; Fri, 20 May 2022 16:10:44 +0100 (BST) Received: from R01UKEXCASM126.r01.fujitsu.local (unknown [10.183.43.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by n03ukasimr03.n03.fujitsu.local (Postfix) with ESMTPS id CC169B53; Fri, 20 May 2022 16:10:44 +0100 (BST) Received: from localhost.localdomain (10.167.220.84) by R01UKEXCASM126.r01.fujitsu.local (10.183.43.178) with Microsoft SMTP Server (TLS) id 15.0.1497.32; Fri, 20 May 2022 16:10:21 +0100 From: Yang Xu To: , CC: , , , , , , Yang Xu Subject: [PATCH v9 3/4] fs: move S_ISGID stripping into the vfs Date: Sat, 21 May 2022 00:10:36 +0800 Message-ID: <1653063037-2461-3-git-send-email-xuyang2018.jy@fujitsu.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1653063037-2461-1-git-send-email-xuyang2018.jy@fujitsu.com> References: <1653063037-2461-1-git-send-email-xuyang2018.jy@fujitsu.com> MIME-Version: 1.0 X-Originating-IP: [10.167.220.84] X-ClientProxiedBy: G08CNEXCHPEKD08.g08.fujitsu.local (10.167.33.83) To R01UKEXCASM126.r01.fujitsu.local (10.183.43.178) X-Virus-Scanned: ClamAV using ClamSMTP Precedence: bulk List-ID: X-Mailing-List: ceph-devel@vger.kernel.org Creating files that have both the S_IXGRP and S_ISGID bit raised in directories that themselves have the S_ISGID bit set requires additional privileges to avoid security issues. When a filesystem creates a new inode it needs to take care that the caller is either in the group of the newly created inode or they have CAP_FSETID in their current user namespace and are privileged over the parent directory of the new inode. If any of these two conditions is true then the S_ISGID bit can be raised for an S_IXGRP file and if not it needs to be stripped. However, there are several key issues with the current state of things: * The S_ISGID stripping logic is entangled with umask stripping. If a filesystem doesn't support or enable POSIX ACLs then umask stripping is done directly in the vfs before calling into the filesystem. If the filesystem does support POSIX ACLs then unmask stripping may be done in the filesystem itself when calling posix_acl_create(). * Filesystems that don't rely on inode_init_owner() don't get S_ISGID stripping logic. While that may be intentional (e.g. network filesystems might just defer setgid stripping to a server) it is often just a security issue. * The first two points taken together mean that there's a non-standardized ordering between setgid stripping in inode_init_owner() and posix_acl_create() both on the vfs level and the filesystem level. The latter part is especially problematic since each filesystem is technically free to order inode_init_owner() and posix_acl_create() however it sees fit meaning that S_ISGID inheritance might or might not be applied. * We do still have bugs in this areas years after the initial round of setgid bugfixes. So the current state is quite messy and while we won't be able to make it completely clean as posix_acl_create() is still a filesystem specific call we can improve the S_SIGD stripping situation quite a bit by hoisting it out of inode_init_owner() and into the vfs creation operations. This means we alleviate the burden for filesystems to handle S_ISGID stripping correctly and can standardize the ordering between S_ISGID and umask stripping in the vfs. The S_ISGID bit is stripped before any umask is applied. This has the advantage that the ordering is unaffected by whether umask stripping is done by the vfs itself (if no POSIX ACLs are supported or enabled) or in the filesystem in posix_acl_create() (if POSIX ACLs are supported). To this end a new helper vfs_prepare_mode() is added which calls the previously added mode_strip_setgid() helper and strips the umask afterwards. All inode operations that create new filesystem objects have been updated to call vfs_prepare_mode() before passing the mode into the relevant inode operation of the filesystems. Care has been taken to ensure that the mode passed to the security hooks is the mode that is seen by the filesystem. Moving S_ISGID stripping from filesystem callpaths into the vfs callpaths means thatfilesystems that call vfs_*() helpers directly can't rely on S_ISGID stripping being done in vfs_*() helpers anymore unless they pass the mode on from a prior run through the vfs. This mostly affects overlayfs which calls vfs_*() functions directly. So a typical overlayfs callstack would be sys_mknod() -> do_mknodat(mode) // calls vfs_prepare_mode() -> .mknod = ovl_mknod(mode) -> ovl_create(mode) -> vfs_mknod(mode) But it is safe as overlayfs passes on the mode on from its own run through the vfs and then via vfs_*() to the underlying filesystem. Following is an overview of the filesystem specific and inode operations specific implications: arch/powerpc/platforms/cell/spufs/inode.c: inode_init_owner(&init_user_ns, inode, dir, mode | S_IFDIR); arch/powerpc/platforms/cell/spufs/inode.c: inode_init_owner(&init_user_ns, inode, dir, mode | S_IFDIR); fs/9p/vfs_inode.c: inode_init_owner(&init_user_ns, inode, NULL, mode); fs/bfs/dir.c: inode_init_owner(&init_user_ns, inode, dir, mode); fs/btrfs/inode.c: inode_init_owner(mnt_userns, inode, dir, mode); fs/btrfs/tests/btrfs-tests.c: inode_init_owner(&init_user_ns, inode, NULL, S_IFREG); fs/ext2/ialloc.c: inode_init_owner(&init_user_ns, inode, dir, mode); fs/ext4/ialloc.c: inode_init_owner(mnt_userns, inode, dir, mode); fs/f2fs/namei.c: inode_init_owner(mnt_userns, inode, dir, mode); fs/hfsplus/inode.c: inode_init_owner(&init_user_ns, inode, dir, mode); fs/hugetlbfs/inode.c: inode_init_owner(&init_user_ns, inode, dir, mode); fs/jfs/jfs_inode.c: inode_init_owner(&init_user_ns, inode, parent, mode); fs/minix/bitmap.c: inode_init_owner(&init_user_ns, inode, dir, mode); fs/nilfs2/inode.c: inode_init_owner(&init_user_ns, inode, dir, mode); fs/ntfs3/inode.c: inode_init_owner(mnt_userns, inode, dir, mode); fs/ocfs2/dlmfs/dlmfs.c: inode_init_owner(&init_user_ns, inode, NULL, mode); fs/ocfs2/dlmfs/dlmfs.c: inode_init_owner(&init_user_ns, inode, parent, mode); fs/ocfs2/namei.c: inode_init_owner(&init_user_ns, inode, dir, mode); fs/omfs/inode.c: inode_init_owner(&init_user_ns, inode, NULL, mode); fs/overlayfs/dir.c: inode_init_owner(&init_user_ns, inode, dentry->d_parent->d_inode, mode); fs/ramfs/inode.c: inode_init_owner(&init_user_ns, inode, dir, mode); fs/reiserfs/namei.c: inode_init_owner(&init_user_ns, inode, dir, mode); fs/sysv/ialloc.c: inode_init_owner(&init_user_ns, inode, dir, mode); fs/ubifs/dir.c: inode_init_owner(&init_user_ns, inode, dir, mode); fs/udf/ialloc.c: inode_init_owner(&init_user_ns, inode, dir, mode); fs/ufs/ialloc.c: inode_init_owner(&init_user_ns, inode, dir, mode); fs/xfs/xfs_inode.c: inode_init_owner(mnt_userns, inode, dir, mode); fs/zonefs/super.c: inode_init_owner(&init_user_ns, inode, parent, S_IFDIR | 0555); kernel/bpf/inode.c: inode_init_owner(&init_user_ns, inode, dir, mode); mm/shmem.c: inode_init_owner(&init_user_ns, inode, dir, mode); All of the above filesystems end up calling inode_init_owner() when new filesystem objects are created through the following ->mkdir(), ->symlink(), ->mknod(), ->create(), ->tmpfile(), ->rename() inode operations. Since directories always inherit the S_ISGID bit with the exception of xfs when irix_sgid_inherit mode is turned on S_ISGID stripping doesn't apply. The ->symlink() inode operation trivially inherit the mode from the target and the ->rename() inode operation inherits the mode from the source inode. All other inode operations will have the S_ISGID bit stripped once in vfs_prepare_mode() before. In addition to this there are filesystems which allow the creation of filesystem objects through ioctl()s or - in the case of spufs - circumventing the vfs in other ways. If filesystem objects are created through ioctl()s the vfs doesn't know about it and can't apply regular permission checking including S_ISGID logic. Therfore, a filesystem relying on S_ISGID stripping in inode_init_owner() in their ioctl() callpath will be affected by moving this logic into the vfs. So we did our best to audit all filesystems in this regard: * btrfs allows the creation of filesystem objects through various ioctls(). Snapshot creation literally takes a snapshot and so the mode is fully preserved and S_ISGID stripping doesn't apply. Creating a new subvolum relies on inode_init_owner() in btrfs_new_inode() but only creates directories and doesn't raise S_ISGID. * ocfs2 has a peculiar implementation of reflinks. In contrast to e.g. xfs and btrfs FICLONE/FICLONERANGE ioctl() that is only concerned with the actual extents ocfs2 uses a separate ioctl() that also creates the target file. Iow, ocfs2 circumvents the vfs entirely here and did indeed rely on inode_init_owner() to strip the S_ISGID bit. This is the only place where a filesystem needs to call mode_strip_sgid() directly but this is self-inflicted pain tbh. * spufs doesn't go through the vfs at all and doesn't use ioctl()s either. Instead it has a dedicated system call spufs_create() which allows the creation of filesystem objects. But spufs only creates directories and doesn't allo S_SIGID bits, i.e. it specifically only allows 0777 bits. * bpf uses vfs_mkobj() but also doesn't allow S_ISGID bits to be created. This patch also changed grpid behaviour for ext4/xfs because the mode passed to them may have been changed by vfs_prepare_mode. While we did our best to audit everything there's a risk of regressions in here. However, for the sake of maintenance and given that we've seen a range of bugs years after S_ISGID inheritance issues were fixed (see [1]-[3]) the risk seems worth taking. In the worst case we will have to revert. Associated with this change is a new set of fstests to enforce the semantics for all new filesystems. Link: e014f37db1a2 ("xfs: use setattr_copy to set vfs inode attributes") [1] Link: 01ea173e103e ("xfs: fix up non-directory creation in SGID directories") [2] Link: fd84bfdddd16 ("ceph: fix up non-directory creation in SGID directories") [3] Reviewed-by: Darrick J. Wong Suggested-by: Dave Chinner Reviewed-and-Tested-by: Jeff Layton Signed-off-by: Yang Xu --- v8->v9: 1.move vfs_prepare_mode info fs/namei.c 2. add grpid behaviour change in commit message 3. also mention the overflay in commit meessage because it will use call vfs_mknod directly fs/inode.c | 2 -- fs/namei.c | 33 ++++++++++++++++++++------------- fs/ocfs2/namei.c | 1 + 3 files changed, 21 insertions(+), 15 deletions(-) diff --git a/fs/inode.c b/fs/inode.c index 37bd85981d38..42ecaf79aaaf 100644 --- a/fs/inode.c +++ b/fs/inode.c @@ -2246,8 +2246,6 @@ void inode_init_owner(struct user_namespace *mnt_userns, struct inode *inode, /* Directories are special, and always inherit S_ISGID */ if (S_ISDIR(mode)) mode |= S_ISGID; - else - mode = mode_strip_sgid(mnt_userns, dir, mode); } else inode_fsgid_set(inode, mnt_userns); inode->i_mode = mode; diff --git a/fs/namei.c b/fs/namei.c index 73646e28fae0..8b60914861f5 100644 --- a/fs/namei.c +++ b/fs/namei.c @@ -2998,6 +2998,17 @@ void unlock_rename(struct dentry *p1, struct dentry *p2) } EXPORT_SYMBOL(unlock_rename); +static inline umode_t vfs_prepare_mode(struct user_namespace *mnt_userns, + const struct inode *dir, umode_t mode) +{ + mode = mode_strip_sgid(mnt_userns, dir, mode); + + if (!IS_POSIXACL(dir)) + mode &= ~current_umask(); + + return mode; +} + /** * vfs_create - create new file * @mnt_userns: user namespace of the mount the inode was found from @@ -3287,8 +3298,7 @@ static struct dentry *lookup_open(struct nameidata *nd, struct file *file, if (open_flag & O_CREAT) { if (open_flag & O_EXCL) open_flag &= ~O_TRUNC; - if (!IS_POSIXACL(dir->d_inode)) - mode &= ~current_umask(); + mode = vfs_prepare_mode(mnt_userns, dir->d_inode, mode); if (likely(got_write)) create_error = may_o_create(mnt_userns, &nd->path, dentry, mode); @@ -3521,8 +3531,7 @@ struct dentry *vfs_tmpfile(struct user_namespace *mnt_userns, child = d_alloc(dentry, &slash_name); if (unlikely(!child)) goto out_err; - if (!IS_POSIXACL(dir)) - mode &= ~current_umask(); + mode = vfs_prepare_mode(mnt_userns, dir, mode); error = dir->i_op->tmpfile(mnt_userns, dir, child, mode); if (error) goto out_err; @@ -3850,13 +3859,12 @@ static int do_mknodat(int dfd, struct filename *name, umode_t mode, if (IS_ERR(dentry)) goto out1; - if (!IS_POSIXACL(path.dentry->d_inode)) - mode &= ~current_umask(); + mnt_userns = mnt_user_ns(path.mnt); + mode = vfs_prepare_mode(mnt_userns, path.dentry->d_inode, mode); error = security_path_mknod(&path, dentry, mode, dev); if (error) goto out2; - mnt_userns = mnt_user_ns(path.mnt); switch (mode & S_IFMT) { case 0: case S_IFREG: error = vfs_create(mnt_userns, path.dentry->d_inode, @@ -3943,6 +3951,7 @@ int do_mkdirat(int dfd, struct filename *name, umode_t mode) struct path path; int error; unsigned int lookup_flags = LOOKUP_DIRECTORY; + struct user_namespace *mnt_userns; retry: dentry = filename_create(dfd, name, &path, lookup_flags); @@ -3950,15 +3959,13 @@ int do_mkdirat(int dfd, struct filename *name, umode_t mode) if (IS_ERR(dentry)) goto out_putname; - if (!IS_POSIXACL(path.dentry->d_inode)) - mode &= ~current_umask(); + mnt_userns = mnt_user_ns(path.mnt); + mode = vfs_prepare_mode(mnt_userns, path.dentry->d_inode, mode); error = security_path_mkdir(&path, dentry, mode); - if (!error) { - struct user_namespace *mnt_userns; - mnt_userns = mnt_user_ns(path.mnt); + if (!error) error = vfs_mkdir(mnt_userns, path.dentry->d_inode, dentry, mode); - } + done_path_create(&path, dentry); if (retry_estale(error, lookup_flags)) { lookup_flags |= LOOKUP_REVAL; diff --git a/fs/ocfs2/namei.c b/fs/ocfs2/namei.c index c75fd54b9185..961d1cf54388 100644 --- a/fs/ocfs2/namei.c +++ b/fs/ocfs2/namei.c @@ -197,6 +197,7 @@ static struct inode *ocfs2_get_init_inode(struct inode *dir, umode_t mode) * callers. */ if (S_ISDIR(mode)) set_nlink(inode, 2); + mode = mode_strip_sgid(&init_user_ns, dir, mode); inode_init_owner(&init_user_ns, inode, dir, mode); status = dquot_initialize(inode); if (status) From patchwork Fri May 20 16:10:37 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yang Xu X-Patchwork-Id: 575437 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A7712C433F5 for ; Fri, 20 May 2022 15:10:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350199AbiETPKy (ORCPT ); Fri, 20 May 2022 11:10:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59892 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350639AbiETPKw (ORCPT ); Fri, 20 May 2022 11:10:52 -0400 Received: from mail1.bemta34.messagelabs.com (mail1.bemta34.messagelabs.com [195.245.231.1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CBB6163A0; Fri, 20 May 2022 08:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fujitsu.com; s=170520fj; t=1653059446; i=@fujitsu.com; bh=AVZvvk8By7v5SnMkr9rpDYtWLxmKN2qhcVg7w2Ws7Pk=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=h5mjKwiGdcrY1dSiefe34rZzXhdQ+9Sm38mtkRjdUTckAAgQw+5sEB6/tY7N9s+J3 UHQi7zCvT3C2kLScv8BHJHJvGUJgm5QzD6s2njXMCXswhJBYGD71jAZmLIaFrXFkKP 9tuvweKbNTVPje+qQx/jdjPyjHEwB/kOUYAWmTMNWisoVpatuY1m4w3327QbuFo1LL 6qMwuSq7Jd9AqzDlhQLhXFDFNpnVOQDmRiL5kDc+dvU0NzvYiu9OU/J/u9kWjOiF7s +nOhgsX/pf55PaQbRQ0GoFizKLHPxRFjn1gjnVej8xyiM8uMmE622C8RK+xfpJetf3 Tmetq0x62o7Ng== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkleJIrShJLcpLzFFi42Kxs+FI0i1d355 kMGGHnsXrw58YLT7cnMRkseXYPUaLy0/4LH4uW8VusWfvSRaL83+Ps1r8/jGHzYHD49QiCY/N K7Q8Nq3qZPP4vEnOY9OTt0wBrFGsmXlJ+RUJrBkLprxnKjjIUXGw/RNbA+N89i5GLg4hgY2ME l9e7GCBcOYySUyfewwqs4dRYv67HUxdjJwcbAKaEs86FzCD2CICjhIv2mewgNjMApsZJZY9Dg exhQXsJG5du8/WxcjBwSKgKvF2lz1ImFfAQ2L9hB1sILaEgILElIfvwcZwCnhKLLjeDVYuBFS zZIEMRLmgxMmZT6CmS0gcfPGCGaJVUeJSxzdGCLtC4vXhS1BxNYmr5zYxT2AUnIWkfRaS9gWM TKsYrZOKMtMzSnITM3N0DQ0MdA0NTXWNjYBME73EKt1EvdRS3fLU4hJdI73E8mK91OJiveLK3 OScFL281JJNjMBYSSlWyNjB+H3lT71DjJIcTEqivKUr2pOE+JLyUyozEosz4otKc1KLDzHKcH AoSfDmrAHKCRalpqdWpGXmAOMWJi3BwaMkwiu/FijNW1yQmFucmQ6ROsWoy/H0+Ym9zEIsefl 5qVLivHbrgIoEQIoySvPgRsBSyCVGWSlhXkYGBgYhnoLUotzMElT5V4ziHIxKwryqq4Gm8GTm lcBtegV0BBPQEbeUW0GOKElESEk1MCVICcRH7dqxt0yEKaw1uWR3xpkrzxdLbDqwV7ap98f0y 5f/RFS/yVRKfjMnc2NJpEgt0x2FTfeCjH96MWs4Sk/cdWa9j3y1k4Hj7vm3GhXmbZmcsaMksa yFV97MnqVmeRJv9BEZPtmGDmXuM33tHfE/vgvz1MzzdH8YN+Vh3JXXy4wMNU7LiVdtcbzsNWn 3GaUEluOS1zevepwZJPV9xmP2kgJNMyWePZmNV64etY5YuTDd7R8v45ecxmcZJrqB8z8cW7R/ 4Zqilid9hxNr/Cd9+hA3e53tItmytw/lUuyTc6ZXfTPQ8nferfZ0/xlN+R+/7hnYrS7cyev5/ eqNVtmZj1faL2c1i7hmvG/lVCWW4oxEQy3mouJEANr3H0GcAwAA X-Env-Sender: xuyang2018.jy@fujitsu.com X-Msg-Ref: server-9.tower-571.messagelabs.com!1653059445!68088!1 X-Originating-IP: [62.60.8.98] X-SYMC-ESS-Client-Auth: outbound-route-from=pass X-StarScan-Received: X-StarScan-Version: 9.86.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6459 invoked from network); 20 May 2022 15:10:45 -0000 Received: from unknown (HELO n03ukasimr03.n03.fujitsu.local) (62.60.8.98) by server-9.tower-571.messagelabs.com with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 20 May 2022 15:10:45 -0000 Received: from n03ukasimr03.n03.fujitsu.local (localhost [127.0.0.1]) by n03ukasimr03.n03.fujitsu.local (Postfix) with ESMTP id 13A2AD75; Fri, 20 May 2022 16:10:45 +0100 (BST) Received: from R01UKEXCASM126.r01.fujitsu.local (unknown [10.183.43.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by n03ukasimr03.n03.fujitsu.local (Postfix) with ESMTPS id D635BB5C; Fri, 20 May 2022 16:10:44 +0100 (BST) Received: from localhost.localdomain (10.167.220.84) by R01UKEXCASM126.r01.fujitsu.local (10.183.43.178) with Microsoft SMTP Server (TLS) id 15.0.1497.32; Fri, 20 May 2022 16:10:32 +0100 From: Yang Xu To: , CC: , , , , , , Yang Xu Subject: [PATCH v9 4/4] ceph: rely on vfs for setgid stripping Date: Sat, 21 May 2022 00:10:37 +0800 Message-ID: <1653063037-2461-4-git-send-email-xuyang2018.jy@fujitsu.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1653063037-2461-1-git-send-email-xuyang2018.jy@fujitsu.com> References: <1653063037-2461-1-git-send-email-xuyang2018.jy@fujitsu.com> MIME-Version: 1.0 X-Originating-IP: [10.167.220.84] X-ClientProxiedBy: G08CNEXCHPEKD08.g08.fujitsu.local (10.167.33.83) To R01UKEXCASM126.r01.fujitsu.local (10.183.43.178) X-Virus-Scanned: ClamAV using ClamSMTP Precedence: bulk List-ID: X-Mailing-List: ceph-devel@vger.kernel.org Now that we finished moving setgid stripping for regular files in setgid directories into the vfs, individual filesystem don't need to manually strip the setgid bit anymore. Drop the now unneeded code from ceph. Reviewed-by: Xiubo Li Reviewed-by: Christian Brauner (Microsoft) Reviewed-and-Tested-by: Jeff Layton Signed-off-by: Yang Xu --- fs/ceph/file.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/fs/ceph/file.c b/fs/ceph/file.c index 8c8226c0feac..257ec53b1765 100644 --- a/fs/ceph/file.c +++ b/fs/ceph/file.c @@ -657,10 +657,6 @@ static int ceph_finish_async_create(struct inode *dir, struct dentry *dentry, /* Directories always inherit the setgid bit. */ if (S_ISDIR(mode)) mode |= S_ISGID; - else if ((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP) && - !in_group_p(dir->i_gid) && - !capable_wrt_inode_uidgid(&init_user_ns, dir, CAP_FSETID)) - mode &= ~S_ISGID; } else { in.gid = cpu_to_le32(from_kgid(&init_user_ns, current_fsgid())); }