From patchwork Thu Sep 29 15:30:28 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christian Brauner X-Patchwork-Id: 1684536 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org (client-ip=2620:137:e000::1:20; helo=out1.vger.email; envelope-from=linux-cifs-owner@vger.kernel.org; receiver=) Authentication-Results: legolas.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=TRO3ASCB; dkim-atps=neutral Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by legolas.ozlabs.org (Postfix) with ESMTP id 4MdcpX4McFz1yqS for ; Fri, 30 Sep 2022 01:33:56 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235677AbiI2Pdw (ORCPT ); Thu, 29 Sep 2022 11:33:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48784 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235935AbiI2Pc3 (ORCPT ); Thu, 29 Sep 2022 11:32:29 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 76BC015D653; Thu, 29 Sep 2022 08:31:43 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 2C3ACB824F3; Thu, 29 Sep 2022 15:31:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BCA4FC433D7; Thu, 29 Sep 2022 15:31:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1664465500; bh=f/aTVwuhBnw5pyq4Y5ANfr+wkoZkxl/SPBIG+t0UB60=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TRO3ASCB/Ml5bCmUwPFvFCBGsi7bngR6wKzcWt5CKAk0FtVHmTp6V3662DMrsYHzb xdOztxhLH1yAw7Es5p4v1Fme068psJtT+3ni2fP7vY4OEPxyKSppJeji0k8PGDoHpT pQK5+CBuKfpoQzxfQfqqYNSOC8AwpCGIbfqzRHDZbmriDdV/GqwEUNzCjo5qF8DeK7 k/ixaGlQqUe0ZruF5de+pcPWxELVt6LlS0y7yb52+yFgNX49hk6yn8bQM9EAJ4Cc99 QJeQhyufhNOoHee5b9EJt62gHDjhog3HG+MlLgujLjppnjVJLT1bVvRcpgRFdJwxPw sVRDlaKhPev6w== From: Christian Brauner To: linux-fsdevel@vger.kernel.org Cc: Christian Brauner , Seth Forshee , Christoph Hellwig , Al Viro , Steve French , Paulo Alcantara , Ronnie Sahlberg , Shyam Prasad N , Hyunchul Lee , Sergey Senozhatsky , linux-cifs@vger.kernel.org, linux-security-module@vger.kernel.org Subject: [PATCH v4 18/30] ksmbd: use vfs_remove_acl() Date: Thu, 29 Sep 2022 17:30:28 +0200 Message-Id: <20220929153041.500115-19-brauner@kernel.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220929153041.500115-1-brauner@kernel.org> References: <20220929153041.500115-1-brauner@kernel.org> MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=1756; i=brauner@kernel.org; h=from:subject; bh=f/aTVwuhBnw5pyq4Y5ANfr+wkoZkxl/SPBIG+t0UB60=; b=owGbwMvMwCU28Zj0gdSKO4sYT6slMSSb7hKd9pNns+ep/siDy16u3HDoTSq7cHDxQdt67+flHGxM NzkdOkpZGMS4GGTFFFkc2k3C5ZbzVGw2ytSAmcPKBDKEgYtTACayP4WR4dQjoZLzJh8L/xsenhZ77H Z69teNLxf7tvQ4/c95zvR5hzHDPx2x4PcFy7+p+P06IWq0psjuXgizY8I2ISbzKXrqnOd4GQA= X-Developer-Key: i=brauner@kernel.org; a=openpgp; fpr=4880B8C9BD0E5106FC070F4F7B3C391EFEA93624 X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-cifs@vger.kernel.org The current way of setting and getting posix acls through the generic xattr interface is error prone and type unsafe. The vfs needs to interpret and fixup posix acls before storing or reporting it to userspace. Various hacks exist to make this work. The code is hard to understand and difficult to maintain in it's current form. Instead of making this work by hacking posix acls through xattr handlers we are building a dedicated posix acl api around the get and set inode operations. This removes a lot of hackiness and makes the codepaths easier to maintain. A lot of background can be found in [1]. Now that we've switched all filesystems that can serve as the lower filesystem for ksmbd we can switch ksmbd over to rely on the posix acl api. Note that this is orthogonal to switching the vfs itself over. Link: https://lore.kernel.org/all/20220801145520.1532837-1-brauner@kernel.org [1] Signed-off-by: Christian Brauner (Microsoft) --- Notes: /* v2 */ unchanged /* v3 */ unchanged /* v4 */ unchanged fs/ksmbd/vfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ksmbd/vfs.c b/fs/ksmbd/vfs.c index f350d98872f9..0364c64d8e3f 100644 --- a/fs/ksmbd/vfs.c +++ b/fs/ksmbd/vfs.c @@ -1311,7 +1311,7 @@ int ksmbd_vfs_remove_acl_xattrs(struct user_namespace *user_ns, sizeof(XATTR_NAME_POSIX_ACL_ACCESS) - 1) || !strncmp(name, XATTR_NAME_POSIX_ACL_DEFAULT, sizeof(XATTR_NAME_POSIX_ACL_DEFAULT) - 1)) { - err = ksmbd_vfs_remove_xattr(user_ns, dentry, name); + err = vfs_remove_acl(user_ns, dentry, name); if (err) ksmbd_debug(SMB, "remove acl xattr failed : %s\n", name);