From: Sun YangKai <sunk67188@gmail.com>
To: linux-btrfs@vger.kernel.org, fstests@vger.kernel.org
Cc: sunyangkai@fygo.io, Filipe Manana <fdmanana@suse.com>
Subject: [PATCH v3] btrfs: test POSIX ACL changes for RO btrfs property
Date: Wed, 22 Jul 2026 15:52:47 +0800 [thread overview]
Message-ID: <20260722075347.26639-1-sunk67188@gmail.com> (raw)
In-Reply-To: <20260709082500.17907-2-sunk67188@gmail.com>
From: Sun YangKai <sunyangkai@fygo.io>
Test creation, modification and deletion of POSIX ACLs on a btrfs
filesystem that has the read-only property set to true.
This exercises a bug fixed by the kernel patch with subject:
"btrfs: check if root is readonly when setting posix acl"
Signed-off-by: Sun YangKai <sunyangkai@fygo.io>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
---
Changes since v2:
- updated commit message
- proper format for fixed_by_kernel_commit
- lower case variable name
- handle mkfs failure
Suggested by Filipe Manana
---
tests/btrfs/353 | 95 +++++++++++++++++++++++++++++++++++++++++++++
tests/btrfs/353.out | 39 +++++++++++++++++++
2 files changed, 134 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..63ba4681
--- /dev/null
+++ b/tests/btrfs/353
@@ -0,0 +1,95 @@
+#! /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
+
+_fixed_by_kernel_commit xxxxxxxxxxxx \
+ "btrfs: check if root is readonly when setting posix acl"
+
+_require_acls
+_require_btrfs_command "property"
+_require_scratch
+
+_scratch_mkfs >> $seqres.full 2>&1 || _fail "mkfs failed"
+_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
prev parent reply other threads:[~2026-07-22 7:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-09 8:23 [PATCH v2] btrfs: check if root is readonly when setting posix acl Sun YangKai
2026-07-09 9:54 ` Johannes Thumshirn
2026-07-09 10:43 ` Filipe Manana
2026-07-10 9:03 ` Sun YangKai
2026-07-13 9:06 ` [PATCH] btrfs: test POSIX ACL changes for RO btrfs property Sun YangKai
2026-07-13 9:44 ` [PATCH v2] " Sun YangKai
2026-07-20 16:16 ` Filipe Manana
2026-07-22 1:41 ` Sun YangKai
2026-07-20 16:03 ` [PATCH v2] btrfs: check if root is readonly when setting posix acl Filipe Manana
2026-07-22 1:38 ` Sun YangKai
2026-07-22 7:52 ` Sun YangKai [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260722075347.26639-1-sunk67188@gmail.com \
--to=sunk67188@gmail.com \
--cc=fdmanana@suse.com \
--cc=fstests@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=sunyangkai@fygo.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.