Received: by 2002:ab2:6857:0:b0:1ef:ffd0:ce49 with SMTP id l23csp219490lqp; Wed, 20 Mar 2024 20:58:07 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCU5247zCo60jHeCsHt7S4czvQkQrjrQiWqQuCwi+bkGvHOLiQsy8+YT6ATbd7Z/uNDRX4xMLOyZfsya4fBFBH9MO/drYrNvY+KRkdq0Pw== X-Google-Smtp-Source: AGHT+IG2KKn7K2wHk3HHbtuPJDbAdV04puXIIfCrH/AO0E8NdXDhPeoD5cXrviwFeqgc/3eOhqPw X-Received: by 2002:a05:6870:fba2:b0:21e:635c:a5b9 with SMTP id kv34-20020a056870fba200b0021e635ca5b9mr22621022oab.52.1710993487187; Wed, 20 Mar 2024 20:58:07 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1710993487; cv=pass; d=google.com; s=arc-20160816; b=c7wHUSWDFaOeWD6kPMd7paEkv0DiaDFCSE5axPcVmqhNs9R7fGm7kUIUPEXz/IJlXg vx+TVkU41tuXXvQQiTkiKy9yKQS1ewNiUuJ6Zq9N8pB6ZlteT2R7zKrNCQRy2ywnOg9m qipws2Z7O/sJBMw/L6dWLArSNLliNSB2SMOsYWr+pqbGLgke8tnDDLrXoDyktWmOxG6+ WzE2+xpJCfQYWBp7AlxYjOCfVFfE2hCbu6AomzRqwYF9jzV2Tbe6YvyCgRnMYXIxsLcY kqRZLwp0hHESCVqP894xDAsO1qfjyXt+NsvBMmVpbrRdV4gRvX87pWeo/shFWwsPhdSK wfEw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:user-agent:date:message-id:from :references:cc:to:subject; bh=mfGunayavDzPA0NF3WX+SP0J+UNotb4D4rFZYYyyYu8=; fh=RtLWWpEP4gFwxDxzRZoRDYCDh8uZfLWj32HoVoXIG0Q=; b=P1hdZZCV6CwDKUsGgXPbibc9exrc+0nzer07S3X+wPHiwCxAggDLST70RxV3F60Bng M+VZdCwzqOtymXvuld/pD6QA7mthcuq3xvRZx+bOUPewH0R0xxeYr4fp9+SjYTUZTsj3 2zAo3Yqj+OQXPO1CZyIjLgfJ7u10EKu8+DP6/9gKQ+RG0x0rCGHFqjVTNJTqDXcllLPl G0ldhKAmaPhaG6fPaRPBB3H7yM+w8j2UqVWnhxa3C0lq0LUexPZiH5ypuCLf8jynJ8ty uS0NPt0nlKBAW7PBcHlqX0ep+SizL/iP+uaTV1F34llgl4F2rJs4A6C/K8x7ulbFS+UX 3fww==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=huawei.com dmarc=pass fromdomain=huawei.com); spf=pass (google.com: domain of linux-kernel+bounces-109633-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-109633-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id z9-20020aa78889000000b006e704db4049si11084011pfe.101.2024.03.20.20.58.06 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Mar 2024 20:58:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-109633-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=huawei.com dmarc=pass fromdomain=huawei.com); spf=pass (google.com: domain of linux-kernel+bounces-109633-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-109633-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id C91CE2822A8 for ; Thu, 21 Mar 2024 03:48:15 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 29685B673; Thu, 21 Mar 2024 03:48:11 +0000 (UTC) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ECB8D8F45 for ; Thu, 21 Mar 2024 03:48:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.189 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710992890; cv=none; b=afsz5/HMjEZvfdWVptqT1T/qCpSnDeS+tUSw+DKvTSbXOP//i/8dgA6RsVihmK7ud3NvSU3Xf15le1g0TkfD1VtmgFbzZZafMQmT3RGC/6v6+GMFUJVR2qW5byVO+9PGgmdiVvF+6sDeb2bCWAnIwgZcS6Y8MjGzF9/u1czDssw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710992890; c=relaxed/simple; bh=6QNI8buEq7UTX/W/unqutDITvGcOVJBmsU7RWxjS088=; h=Subject:To:CC:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type; b=j1+piig7cIGTIb7qP5UFnxAkCxPml7KHjYYRNAR08NTDAnurZox3ZImORCFHsm5f/6GE3D31q7jUGjV7LOrtKbPbwDP/vo5gjaUN60NEr7oXDP1TbcVUuTldUd4qo4IKuwYp0yaRvGUMR5AwJvcT/TWWGalEzAKeEdSQNJMA8/Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=45.249.212.189 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.19.88.105]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4V0Wb039dMzNmCY; Thu, 21 Mar 2024 11:46:04 +0800 (CST) Received: from kwepemm600013.china.huawei.com (unknown [7.193.23.68]) by mail.maildlp.com (Postfix) with ESMTPS id 7D216140390; Thu, 21 Mar 2024 11:47:58 +0800 (CST) Received: from [10.174.178.46] (10.174.178.46) by kwepemm600013.china.huawei.com (7.193.23.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Thu, 21 Mar 2024 11:47:57 +0800 Subject: Re: [RFC PATCH 2/5] ubifs: Initialize or update ACLs for inode To: Li Zetao , CC: , References: <20240319161646.2153867-1-lizetao1@huawei.com> <20240319161646.2153867-3-lizetao1@huawei.com> From: Zhihao Cheng Message-ID: <2991c168-723d-48ef-8420-61e22a897239@huawei.com> Date: Thu, 21 Mar 2024 11:47:56 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 In-Reply-To: <20240319161646.2153867-3-lizetao1@huawei.com> Content-Type: text/plain; charset="gbk"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To kwepemm600013.china.huawei.com (7.193.23.68) ?? 2024/3/20 0:16, Li Zetao ะด??: > There are two scenarios where ACL needs to be updated, the first one > is when creating the inode, and the second one is in the chmod process. > When creating directories/files/device node/tmpfile, ACLs needs to be > initialized, but symlink do not.Why not support symlink? It looks like many filesystems(eg. ext4, f2fs, btrfs) support it, except xfs. > > Signed-off-by: Li Zetao > --- > fs/ubifs/dir.c | 16 ++++++++++++++++ > fs/ubifs/file.c | 4 ++++ > 2 files changed, 20 insertions(+) > > diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c > index 551148de66cd..dfb6823cc953 100644 > --- a/fs/ubifs/dir.c > +++ b/fs/ubifs/dir.c > @@ -316,6 +316,10 @@ static int ubifs_create(struct mnt_idmap *idmap, struct inode *dir, > goto out_fname; > } > > + err = ubifs_init_acl(inode, dir); > + if (err) > + goto out_inode; > + Attention, a new inconsistent problem point is imported by acl xattr creation. See https://bugzilla.kernel.org/show_bug.cgi?id=218309. @Richard > err = ubifs_init_security(dir, inode, &dentry->d_name); > if (err) > goto out_inode; > @@ -466,6 +470,10 @@ static int ubifs_tmpfile(struct mnt_idmap *idmap, struct inode *dir, > } > ui = ubifs_inode(inode); > > + err = ubifs_init_acl(inode, dir); > + if (err) > + goto out_inode; > + > err = ubifs_init_security(dir, inode, &dentry->d_name); > if (err) > goto out_inode; > @@ -1013,6 +1021,10 @@ static int ubifs_mkdir(struct mnt_idmap *idmap, struct inode *dir, > goto out_fname; > } > > + err = ubifs_init_acl(inode, dir); > + if (err) > + goto out_inode; > + > err = ubifs_init_security(dir, inode, &dentry->d_name); > if (err) > goto out_inode; > @@ -1108,6 +1120,10 @@ static int ubifs_mknod(struct mnt_idmap *idmap, struct inode *dir, > ui->data = dev; > ui->data_len = devlen; > > + err = ubifs_init_acl(inode, dir); > + if (err) > + goto out_inode; > + > err = ubifs_init_security(dir, inode, &dentry->d_name); > if (err) > goto out_inode; The whiteout inode is not set acl for rename(WHITEOUT) operation. It looks like many filesystems(eg. ext4, f2fs, btrfs) support it, except xfs. In my opinion, whiteout is a char dev, since char/block device is supported, why not support whiteout? If we support whiteout, we should make sure that the whiteout renameing operation is atomic[1]. But I cannot come up with an idea how to combine whiteout xattr(acl) creation and whiteout file creation into an atomic operation, just like problem mentioned in [2], [1] https://lore.kernel.org/linux-mtd/20211227032246.2886878-6-chengzhihao1@huawei.com/ [2] https://bugzilla.kernel.org/show_bug.cgi?id=218309 > diff --git a/fs/ubifs/file.c b/fs/ubifs/file.c > index 5029eb3390a5..8f964f8b0f96 100644 > --- a/fs/ubifs/file.c > +++ b/fs/ubifs/file.c > @@ -41,6 +41,7 @@ > #include > #include > #include > +#include > > static int read_block(struct inode *inode, void *addr, unsigned int block, > struct ubifs_data_node *dn) > @@ -1298,6 +1299,9 @@ int ubifs_setattr(struct mnt_idmap *idmap, struct dentry *dentry, > else > err = do_setattr(c, inode, attr); > > + if (!err && (attr->ia_valid & ATTR_MODE)) > + err = posix_acl_chmod(idmap, dentry, inode->i_mode); > + > return err; > } > >