linux-kernel - Re: [Question] nfsacl: why deny owner mode when deny user

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <8e49b767-f2c7-4cba-8477-d3b329ad9d18@app.fastmail.com>
Date: Wed, 24 Dec 2025 10:18:07 -0500
From: "Chuck Lever" <cel@...nel.org>
To: "zhangjian (CG)" <zhangjian496@...wei.com>, stfrench@...rosoft.com,
 "Chuck Lever" <chuck.lever@...cle.com>
Cc: linux-kernel@...r.kernel.org, linux-nfs@...r.kernel.org
Subject: Re: [Question] nfsacl: why deny owner mode when deny user

[ bfields@...hat.com dropped because it's a dead address ]

On Mon, Dec 8, 2025, at 4:56 AM, zhangjian (CG) wrote:
> When user read bit is denied by nfs4_setfacl, owner read bit is also
> denied.
> Example:
>
> [root@...alhost ~]# nfs4_getfacl test/a
> # file: test/a
> A::OWNER@:rwatTcCy
> A::1000:rwatcy
> A::GROUP@:rtcy
> A::EVERYONE@:rtcy
>
> [root@...alhost ~]# nfs4_setfacl -a D::1000:r test/a
> [root@...alhost ~]# nfs4_getfacl test/a
> # file: test/a
> D::OWNER@:r
> A::OWNER@:watTcCy
> D::1000:r
> A::1000:watcy
> A::GROUP@:rtcy
> A::EVERYONE@:rtcy
>
> In function process_one_v4_ace, I see read bit is denied for owner:
> case ACL_USER:
> 	i = find_uid(state, state->users, ace->who);
> 	if (ace->type == NFS4_ACE_ACCESS_ALLOWED_ACE_TYPE) {
> 		allow_bits(&state->users->aces[i].perms, mask);
> 	} else {
> 		deny_bits(&state->users->aces[i].perms, mask);
> 		mask = state->users->aces[i].perms.deny;
> 		deny_bits(&state->owner, mask);
> 	}
> This change is commit in 09229ed. But I wonder why it is implemented
> like this.

I'm not an ACL expert. But here's a stab at an answer.

NFSD must translate incoming NFSv4 ACLs to POSIX ACLs before
they can be stored by local POSIX file systems. The root issue
is the semantic mismatch between NFSv4 ACLs and POSIX ACLs. 

In particular, NFSv4 ACL evaluation is strictly ordered
top-to-bottom. A DENY ACE early in the list blocks access even
if a later ALLOW would grant it.

However, POSIX ACL evaluation uses a fixed priority:
1. If user is the file owner -> use ACL_USER_OBJ entry
2. Else if user matches a named user -> use that ACL_USER
   entry (masked)
3. Else if user's groups match -> use group entries (masked)
4. Else -> use ACL_OTHER

For example:
  DENY uid=1000: READ
  ALLOW OWNER@: READ

Under NFSv4 semantics, if the file owner IS uid=1000, they are
denied READ (the DENY comes first in the ordered evaluation).

But in POSIX ACL semantics, the owner entry (ACL_USER_OBJ) is
checked before any named user entries. If the code only denied
READ to the named user entry without also denying it to the
owner entry, then when uid=1000 owns the file, they would get
READ through the owner check -- bypassing the intended denial.

Commit 09229edb68a3 explicitly states:
> errs on the side of restricting permissions...the posix acl
> produced should be the most permissive acl that is not more
> permissive than the given nfsv4 acl.

The algorithm doesn't know at ACL-setting time whether the
owner might match a named user (or might later via chown), so
it defensively denies to both. This guarantees the POSIX ACL
is never more permissive than the NFSv4 ACL was intended to be.

The downside is that when the owner is NOT the named user, the
owner's permissions are unnecessarily restricted. This is the
cost of the conservative approach: it may deny more than
strictly necessary, but it will never allow more than intended.

A "perfect" translation isn't possible because the semantic
models differ fundamentally. The algorithm  chose correctness
over permissiveness.

-- 
Chuck Lever