From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj2-f3.google.com (mail-pj2-f3.google.com [74.125.227.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0A265299943 for ; Mon, 13 Jul 2026 09:46:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.227.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783935992; cv=none; b=NnrFxr8zapMzNjXGh+yF1LYN/2z3rtqdmHTcU1GWLtUEt6j542AxT/xDwDeE0/LTmtLPUfACHJQAofD/FYMKHREMAU3kmwChdqmZSjvPklHEA56X8EkCJ+Pln7m/HdQMCyzGKfkWJx9y3GSgimft34V4EOWQmjDsLtQGv00A858= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783935992; c=relaxed/simple; bh=j1OujOAkhmdEz9wIazkkKYKxu5okbrWlVFw8M3oM23g=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=DnODUn/R5BlWOFmi8+p75y33NugpUFh9fYUaN08UBQGJ3pVR0LC6UqHme/QxW2O2SNVr+TwV1wfztlVcwzSpWkWykH1NiJvK/P8esZp3MvvH9kD1Q4+jKcUba6Kv1FzL1VlGnOTLbXmTFLZ/qe7+QD4BaQWAlk0ToIWUYx3oH8c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Gws5VJq+; arc=none smtp.client-ip=74.125.227.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Gws5VJq+" Received: by mail-pj2-f3.google.com with SMTP id d9443c01a7336-2cc80c24be6so5020595ad.0 for ; Mon, 13 Jul 2026 02:46:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783935990; x=1784540790; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=93sI+IwfvRptO+HYoHBUpfJ+E/bC1rcpl579TmR5Dzo=; b=Gws5VJq+ZPknmtwZclxnKSOYMFs9X0Up84ZOk4b83HWVXy8dc0gTy71Kkkt3lFjK+A XAhjUaEYt21KnBQ+SqtkJ9skOgMVVhyhWHsuAULX0XaBARs2FaxSmIx5skWtVpGSPP3Z 5BZSyn+0XUd/A2SzO/MGDAM/FuULxzisRFB96PVCpDnj77LjqgpCC7zYDceIeuOjQe1i ibCsLMQcemuGOj28aJLTc/UUyQrbf1SOrVrDvDXlQvKTS8xFyo+wUfJUXyYSPmxJIiKG 9BBJZzkzh7sfP+eHZBcUIRIR+SFwZHmEqAemjqRqjpH8CnuYI4EkvLdKzTRgwP/OqQNa 8u2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783935990; x=1784540790; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=93sI+IwfvRptO+HYoHBUpfJ+E/bC1rcpl579TmR5Dzo=; b=rcPEfCS+BI4Q5cwto0Rc/sIHDCVoGaHcL/JRSezMZsvEmbig0id6ta9suqtB4qm4mU /dnWCf89x1nUYeaGf3pGpHBie0IzNJ7axmpTbQvGX+vOsNK0ofO18hdaxccF04EKcqb3 1NN8EZWFoLIEURkBaJL9a0vK/8nSuRVfZVlnFWh8WhM2tTKlVs0fGw9SSDdLf1d2H9bB PCtOsVJN4Ztxvf5tPWtxdq7aFJpeA13/soGndDeJq9NBYr6aMZ5nm2kshElRMirLGDL0 nJsFQuVhfKBThi/wCCLG4dVG63fKlGvffVfZPjhyRnd8qIIJ+Xwk0iHx6ZAH+RDnVnZS VJag== X-Forwarded-Encrypted: i=1; AHgh+RohVpZpz1GaSOiGdBiaBSCKd+sYYOd07bEfSykQAQl5dJJ82iQhDVs9KHAk6vAEHnVNMQKyPlB5@vger.kernel.org X-Gm-Message-State: AOJu0YwoSZxirShMHDOvg5b+EbjKCJIlUEjgD2oTwQvN51z24GhwkqeZ ii85r6FEk2nm4LM6aX7+OeKuPJWG0XBIV1tm/06qjmehbWT9+nSkoMft X-Gm-Gg: AfdE7cl4YclducgNQFGERxZPxk2+at5hYmSP+bHZebdNW0PGBxR9OuqRX7xAXlGiwXE Jya3spZjRYtwssh1SkyM3I0rAhJHsDfcOqARX27DnwqpHVsNJ07UrzIp4COzap4kP3O8IIRrE+e SqGxvunnVxMaEtstUWSIfwCk3DnX3AEiLX2jWetflKrFXhdzThNbtRaVR3cqiJFx0t/vPY+qV3x WrXTsXVDSwMdAioAKyuohO7HOXHS/nAvGaCD9B3z6LBJ9zvIr8H+txUwvCjH65MH2ZkgChE8kng z84Wc+ZK0Jc0T6UVDvVvOO+0084h4U+DZ3aYRwftUDPpAC0z/spCsMV3ta2lKKRFaWwTWKJL9CT jx0nwjb10yysVCQbnXrUFb7zzbhnDpBF4ExzMxFdzYXC9GGsvv9h/hTNkcSOmOTW5w4+qYs0ajS 2VDFECWwDgQl4wGQ80OvuwktyIo5xsNfCiqWZffI2L X-Received: by 2002:a17:90b:2dc1:b0:37f:e7e7:ad1 with SMTP id 98e67ed59e1d1-38dc7c0eb95mr6214329a91.5.1783935990320; Mon, 13 Jul 2026 02:46:30 -0700 (PDT) Received: from SaltyKitkat ([154.83.91.239]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-38a5574ca88sm6167713a91.7.2026.07.13.02.46.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Jul 2026 02:46:29 -0700 (PDT) From: Sun YangKai To: linux-btrfs@vger.kernel.org, fstests@vger.kernel.org Cc: Sun YangKai Subject: [PATCH v2] btrfs: test POSIX ACL changes for RO btrfs property Date: Mon, 13 Jul 2026 17:44:45 +0800 Message-ID: <20260713094611.19703-1-sunk67188@gmail.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260709082500.17907-2-sunk67188@gmail.com> References: <20260709082500.17907-2-sunk67188@gmail.com> Precedence: bulk X-Mailing-List: fstests@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Sun YangKai Test creation, modification and deletion of POSIX ACLs on a btrfs filesystem that has the read-only property set to true, and re-test the same after the property is cleared. Commit 353c2ea735e4 ("btrfs: remove redundant readonly root check in btrfs_setxattr_trans") removed the read-only root check from btrfs_setxattr_trans() under the assumption that none of its callers can run on a read-only root. That assumption does not hold for the ->set_acl path: btrfs_set_acl() -> __btrfs_set_acl() reaches btrfs_setxattr_trans() directly, bypassing the handler-level read-only checks that were later (re)added by commit b51111271b03 ("btrfs: check if root is readonly while setting security xattr"). As a result, ACLs could still be set or removed on a read-only subvolume, bypassing the RO protection that applies to every other xattr. The restoring kernel fix adds the read-only check directly to btrfs_set_acl(). This test complements btrfs/275, which covers the generic ->setxattr path. The test exercises the set, get and remove cycle of an access ACL on a regular file, and expects all modifications to fail with EROFS while the subvolume is read-only, then succeed once it is writable again. Signed-off-by: Sun YangKai --- Changes from v1: - fix copywrite header - better wording for commit message Sorry for bothering. --- tests/btrfs/353 | 97 +++++++++++++++++++++++++++++++++++++++++++++ tests/btrfs/353.out | 39 ++++++++++++++++++ 2 files changed, 136 insertions(+) create mode 100755 tests/btrfs/353 create mode 100644 tests/btrfs/353.out diff --git a/tests/btrfs/353 b/tests/btrfs/353 new file mode 100755 index 00000000..586f722a --- /dev/null +++ b/tests/btrfs/353 @@ -0,0 +1,97 @@ +#! /bin/bash +# SPDX-License-Identifier: GPL-2.0 +# Copyright (C) 2026 Fygo OS. All Rights Reserved. +# +# FS QA Test No. 353 +# +# Test that POSIX ACLs cannot be changed once a btrfs subvolume has the +# read-only property set. +# +# Setting or removing a POSIX ACL goes through the ->set_acl inode +# operation, which is a different code path from the generic ->setxattr +# one covered by btrfs/275. It used to be allowed on a read-only +# subvolume and thus bypassed the RO protection. Such modifications must +# fail with EROFS, just like any other xattr. +# +. ./common/preamble +_begin_fstest auto quick acl attr + +. ./common/filter +. ./common/attr + +# TODO: fill in the kernel commit hash that fixes the ->set_acl path once +# it is merged. +# _fixed_by_kernel_commit \ +# "btrfs: check if root is readonly when setting posix acl" + +_require_acls +_require_btrfs_command "property" +_require_scratch + +_scratch_mkfs >> $seqres.full 2>&1 +_scratch_mount + +FILENAME=$SCRATCH_MNT/foo + +set_acl() +{ + local perm=$1 + + # Use -n so setfacl does not recalculate the mask, keeping the + # golden output deterministic regardless of the named user's + # permissions. + setfacl -n -m u:$acl2:$perm,m::rwx $FILENAME 2>&1 | _filter_scratch +} + +get_acl() +{ + getfacl --absolute-names -n $FILENAME | _filter_scratch | _getfacl_filter_id +} + +del_acl() +{ + setfacl -b $FILENAME 2>&1 | _filter_scratch +} + +_acl_setup_ids + +# Create a test file. +echo "hello world" > $FILENAME + +# Set an initial ACL while the subvolume is writable. +set_acl rwx + +# Attempt to change the ACL once the subvolume is read-only. This must +# fail with EROFS. +$BTRFS_UTIL_PROG property set $SCRATCH_MNT ro true +$BTRFS_UTIL_PROG property get $SCRATCH_MNT ro + +set_acl r-- + +# The ACL must not have changed. +get_acl + +# Attempt to remove the ACL from the read-only subvolume. This must +# fail with EROFS as well. +del_acl + +# The ACL must still be present. +get_acl + +# Make the subvolume writable again. +$BTRFS_UTIL_PROG property set $SCRATCH_MNT ro false +$BTRFS_UTIL_PROG property get $SCRATCH_MNT ro + +# Now changing the ACL must succeed. +set_acl r-- + +get_acl + +# And removing it must succeed too. +del_acl + +# Check the ACL is really gone. +get_acl + +status=0 +exit diff --git a/tests/btrfs/353.out b/tests/btrfs/353.out new file mode 100644 index 00000000..66f4a0e5 --- /dev/null +++ b/tests/btrfs/353.out @@ -0,0 +1,39 @@ +QA output created by 353 +ro=true +setfacl: SCRATCH_MNT/foo: Read-only file system +# file: SCRATCH_MNT/foo +# owner: 0 +# group: 0 +user::rw- +user:id2:rwx +group::r-- +mask::rwx +other::r-- + +setfacl: SCRATCH_MNT/foo: Read-only file system +# file: SCRATCH_MNT/foo +# owner: 0 +# group: 0 +user::rw- +user:id2:rwx +group::r-- +mask::rwx +other::r-- + +ro=false +# file: SCRATCH_MNT/foo +# owner: 0 +# group: 0 +user::rw- +user:id2:r-- +group::r-- +mask::rwx +other::r-- + +# file: SCRATCH_MNT/foo +# owner: 0 +# group: 0 +user::rw- +group::r-- +other::r-- + -- 2.54.0