Hello, Could the ACL module maintainers advise on the intended object-identity contract and portability direction for four cases in Gnulib 8f5547126aedc70a9c2cdb7c63829c87c3d71df1?
The descriptor-zero validity check in qcopy_acl is a separate small proposal. The following four cases remain unchanged by that proposal: 1. get_permissions reads the access ACL with acl_get_fd when a valid descriptor is supplied, but reads a directory's default ACL with acl_get_file(name, ACL_TYPE_DEFAULT). 2. set_permissions/set_acls uses acl_set_fd for the access ACL where available, but sets a directory's default ACL with acl_set_file(name, ACL_TYPE_DEFAULT, ...). 3. The corresponding default-ACL deletion uses acl_delete_def_file(name), even with a valid directory descriptor. 4. In qcopy_acl's USE_XATTR branch, a pathname-only source (-1) and a valid positive destination descriptor cause the entire copy to use attr_copy_file. The valid destination descriptor is not used for copying the ACL attributes. The helper comments promise descriptor operations when a descriptor is valid. If a name no longer denotes the opened object, the cases above can mix access/default ACLs from different objects or fail to operate on the selected destination. Local observations: In a private ext4 directory, with all objects owned by UID 1000, I set distinct nontrivial ACLs, opened the objects, then renamed the relevant object and replaced its name with a symlink to a same-owner decoy. - Default-ACL get did not match the default ACL of the opened source. - Default-ACL set and delete did not simultaneously satisfy the expected ACL on the opened destination and an unchanged decoy ACL. - A pathname-only source with a positive destination descriptor also failed the opened-destination/unchanged-decoy checks. All four diagnostics failed on the exact baseline and on the version with only the descriptor-zero validity fix. Stable-name default-ACL controls passed. The six existing copy-acl/set-mode-acl scripts passed before and after without skips. Repeated and fresh builds agreed. These used real Gnulib objects and libacl 2.3.2-2+b1/libattr 2.5.2-3, without mocks or symbol interception; amd64 binaries were user-mode emulated on an ARM64 host. This is a deterministic helper-contract diagnostic, not a demonstrated cross-user exploit. In particular, qcopy_acl's normal USE_XATTR branch is distinct from directly calling the POSIX helpers: these tests do not establish that every downstream CLI reaches each helper path. Overall downstream acceptance remains on HOLD. The library/API background is already public; this is not a claim to have discovered a new CVE. The ACL author's June 29 announcement says that old pathname API semantics are retained for compatibility, while libacl 2.4.0 adds *_at APIs with dirfd/AT_EMPTY_PATH support, including access to a directory's default ACL through its descriptor: https://www.openwall.com/lists/oss-security/2026/06/29/1 https://bugs.debian.org/1141110 Questions for maintainers: - Should these helpers preserve the identity of each supplied valid descriptor for both access and default ACLs, including mixed calls? - On Linux with libacl 2.4.0, would configure-detected *_at APIs using the already-selected descriptor and AT_EMPTY_PATH be the preferred default-ACL approach? - What compatibility behavior should be documented on older libacl or other platforms that cannot operate on default ACLs through an fd? Callers needing stronger guarantees should not mistake a pathname fallback for identity preservation. - How should mixed pathname/descriptor calls be handled without changing downstream symlink-following choices? A blanket NOFOLLOW change or merely using AT_FDCWD with the old name would not answer the per-caller identity/compatibility question. Any eventual adaptation would need default-ACL get/set/delete, access ACL, negative/mixed descriptors, stable-name and renamed-object cases, platform coverage, and downstream CLI-entry tests. A helper-only pass would not establish CLI acceptance. I have checked current Savannah HEAD, relevant recent history and a bounded public mailing-list search without finding a complete equivalent adaptation. That search cannot exclude private discussions or unindexed mail. Tar has separate wrappers; its existing new-API name-conflict fix is not being resubmitted as new work: https://bugs.debian.org/1141146 https://lists.gnu.org/archive/html/bug-tar/2026-06/msg00013.html This AI-assisted message is an RFC and test report, not a larger code contribution. No generated test harness is attached. I am seeking the module maintainers' direction before preparing any larger adaptation or coordinating downstream coreutils/sed/tar changes, rather than splitting generated code to bypass HACKING's contribution rules. Thanks, Eric Cai
