[PATCH v1] NFSD: NFSv4 file creation neglects setting ACL

[PATCH v1] NFSD: NFSv4 file creation neglects setting ACL

[Chuck Lever]

From: Chuck Lever <chuck.lever@oracle.com>

An NFSv4 client that sets an ACL with a named principal during file
creation retrieves the ACL afterwards, and finds that it is only a
default ACL (based on the mode bits) and not the ACL that was
requested during file creation. This violates RFC 8881 section
6.4.1.3: "the ACL attribute is set as given".

The issue occurs in nfsd_create_setattr(), which calls
nfsd_attrs_valid() to determine whether to call nfsd_setattr().
However, nfsd_attrs_valid() checks only for iattr changes and
security labels, but not POSIX ACLs. When only an ACL is present,
the function returns false, nfsd_setattr() is skipped, and the
POSIX ACL is never applied to the inode.

Subsequently, when the client retrieves the ACL, the server finds
no POSIX ACL on the inode and returns one generated from the file's
mode bits rather than returning the originally-specified ACL.

Reported-by: Aurélien Couderc <aurelien.couderc2002@gmail.com>
Fixes: c0cbe70742f4 ("NFSD: add posix ACLs to struct nfsd_attrs")
Cc: Roland Mainz <roland.mainz@nrubsig.org>
X-Cc: stable@vger.kernel.org
Signed-off-by: Chuck Lever <cel@kernel.org>
---
 fs/nfsd/vfs.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/nfsd/vfs.h b/fs/nfsd/vfs.h
index fa46f8b5f132..1dd3ae3ceb3a 100644
--- a/fs/nfsd/vfs.h
+++ b/fs/nfsd/vfs.h
@@ -67,7 +67,8 @@ static inline bool nfsd_attrs_valid(struct nfsd_attrs *attrs)
 	struct iattr *iap = attrs->na_iattr;
 
 	return (iap->ia_valid || (attrs->na_seclabel &&
-		attrs->na_seclabel->len));
+		attrs->na_seclabel->len) ||
+		attrs->na_pacl || attrs->na_dpacl);
 }
 
 __be32		nfserrno (int errno);
-- 
2.51.0

Re: [PATCH v1] NFSD: NFSv4 file creation neglects setting ACL

[Roland Mainz]

On Wed, Nov 19, 2025 at 1:51 AM Chuck Lever <cel@kernel.org> wrote:
>
> From: Chuck Lever <chuck.lever@oracle.com>
>
> An NFSv4 client that sets an ACL with a named principal during file
> creation retrieves the ACL afterwards, and finds that it is only a
> default ACL (based on the mode bits) and not the ACL that was
> requested during file creation. This violates RFC 8881 section
> 6.4.1.3: "the ACL attribute is set as given".
>
> The issue occurs in nfsd_create_setattr(), which calls
> nfsd_attrs_valid() to determine whether to call nfsd_setattr().
> However, nfsd_attrs_valid() checks only for iattr changes and
> security labels, but not POSIX ACLs. When only an ACL is present,
> the function returns false, nfsd_setattr() is skipped, and the
> POSIX ACL is never applied to the inode.
>
> Subsequently, when the client retrieves the ACL, the server finds
> no POSIX ACL on the inode and returns one generated from the file's
> mode bits rather than returning the originally-specified ACL.

The patch works, now ACLs are working at file creation time for both
|EXCLUSIVE4_1| and |UNCHECKED4| (previously it only worked for
|EXCLUSIVE4_1| but not for |UNCHECKED4|).

Reviewed-By: Roland Mainz <roland.mainz@rovema,de>

----

Bye,
Roland
-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

Re: [PATCH v1] NFSD: NFSv4 file creation neglects setting ACL

[Aurélien Couderc]

On Wed, Nov 19, 2025 at 1:51 AM Chuck Lever <cel@kernel.org> wrote:
>
> From: Chuck Lever <chuck.lever@oracle.com>
>
> An NFSv4 client that sets an ACL with a named principal during file
> creation retrieves the ACL afterwards, and finds that it is only a
> default ACL (based on the mode bits) and not the ACL that was
> requested during file creation. This violates RFC 8881 section
> 6.4.1.3: "the ACL attribute is set as given".
>
> The issue occurs in nfsd_create_setattr(), which calls
> nfsd_attrs_valid() to determine whether to call nfsd_setattr().
> However, nfsd_attrs_valid() checks only for iattr changes and
> security labels, but not POSIX ACLs. When only an ACL is present,
> the function returns false, nfsd_setattr() is skipped, and the
> POSIX ACL is never applied to the inode.
>
> Subsequently, when the client retrieves the ACL, the server finds
> no POSIX ACL on the inode and returns one generated from the file's
> mode bits rather than returning the originally-specified ACL.
>
> Reported-by: Aurélien Couderc <aurelien.couderc2002@gmail.com>
> Fixes: c0cbe70742f4 ("NFSD: add posix ACLs to struct nfsd_attrs")
> Cc: Roland Mainz <roland.mainz@nrubsig.org>
> X-Cc: stable@vger.kernel.org
> Signed-off-by: Chuck Lever <cel@kernel.org>

Yes, it works on all affected clients,platforms (Windows
ms-nfs41-client, Windows Exceed NFS4 client, OSX).
Thank you.

Windows test code is at
https://github.com/kofemann/ms-nfs41-client/blob/master/tests/atomiccreatefilewithacl/atomiccreatefilewithacl.ps1

The only thing I did not test was exporting a NFSv4+ filesystem with
Linux CIFS server, and letting Windows CIFS client create a file with
an ACL.

Aurélien
-- 
Aurélien Couderc <aurelien.couderc2002@gmail.com>
Big Data/Data mining expert, chess enthusiast

Re: [PATCH v1] NFSD: NFSv4 file creation neglects setting ACL

[Aurélien Couderc]

On Wed, Nov 19, 2025 at 1:51 AM Chuck Lever <cel@kernel.org> wrote:
>
> From: Chuck Lever <chuck.lever@oracle.com>
>
> An NFSv4 client that sets an ACL with a named principal during file
> creation retrieves the ACL afterwards, and finds that it is only a
> default ACL (based on the mode bits) and not the ACL that was
> requested during file creation. This violates RFC 8881 section
> 6.4.1.3: "the ACL attribute is set as given".
>
> The issue occurs in nfsd_create_setattr(), which calls
> nfsd_attrs_valid() to determine whether to call nfsd_setattr().
> However, nfsd_attrs_valid() checks only for iattr changes and
> security labels, but not POSIX ACLs. When only an ACL is present,
> the function returns false, nfsd_setattr() is skipped, and the
> POSIX ACL is never applied to the inode.
>
> Subsequently, when the client retrieves the ACL, the server finds
> no POSIX ACL on the inode and returns one generated from the file's
> mode bits rather than returning the originally-specified ACL.
>
> Reported-by: Aurélien Couderc <aurelien.couderc2002@gmail.com>
> Fixes: c0cbe70742f4 ("NFSD: add posix ACLs to struct nfsd_attrs")
> Cc: Roland Mainz <roland.mainz@nrubsig.org>
> X-Cc: stable@vger.kernel.org
> Signed-off-by: Chuck Lever <cel@kernel.org>

As said the patch works, but are there any tests in the Linux NFS
testsuite which cover ACLs with multiple users and groups, at OPEN and
SETATTR time?

Aurélien
-- 
Aurélien Couderc <aurelien.couderc2002@gmail.com>
Big Data/Data mining expert, chess enthusiast

Re: [PATCH v1] NFSD: NFSv4 file creation neglects setting ACL

[Chuck Lever]

On Sun, Nov 23, 2025 at 03:54:48PM +0100, Aurélien Couderc wrote:
> On Wed, Nov 19, 2025 at 1:51 AM Chuck Lever <cel@kernel.org> wrote:
> >
> > From: Chuck Lever <chuck.lever@oracle.com>
> >
> > An NFSv4 client that sets an ACL with a named principal during file
> > creation retrieves the ACL afterwards, and finds that it is only a
> > default ACL (based on the mode bits) and not the ACL that was
> > requested during file creation. This violates RFC 8881 section
> > 6.4.1.3: "the ACL attribute is set as given".
> >
> > The issue occurs in nfsd_create_setattr(), which calls
> > nfsd_attrs_valid() to determine whether to call nfsd_setattr().
> > However, nfsd_attrs_valid() checks only for iattr changes and
> > security labels, but not POSIX ACLs. When only an ACL is present,
> > the function returns false, nfsd_setattr() is skipped, and the
> > POSIX ACL is never applied to the inode.
> >
> > Subsequently, when the client retrieves the ACL, the server finds
> > no POSIX ACL on the inode and returns one generated from the file's
> > mode bits rather than returning the originally-specified ACL.
> >
> > Reported-by: Aurélien Couderc <aurelien.couderc2002@gmail.com>
> > Fixes: c0cbe70742f4 ("NFSD: add posix ACLs to struct nfsd_attrs")
> > Cc: Roland Mainz <roland.mainz@nrubsig.org>
> > X-Cc: stable@vger.kernel.org
> > Signed-off-by: Chuck Lever <cel@kernel.org>
> 
> As said the patch works, but are there any tests in the Linux NFS
> testsuite which cover ACLs with multiple users and groups, at OPEN and
> SETATTR time?

I developed several new pynfs [1] tests while troubleshooting this
issue. I'll post them soon.

-- 
Chuck Lever

[1] git://git.linux-nfs.org/projects/cdmackay/pynfs.git

Re: [PATCH v1] NFSD: NFSv4 file creation neglects setting ACL

[Aurélien Couderc]

On Sun, Nov 23, 2025 at 4:46 PM Chuck Lever <cel@kernel.org> wrote:
>
> On Sun, Nov 23, 2025 at 03:54:48PM +0100, Aurélien Couderc wrote:
> > On Wed, Nov 19, 2025 at 1:51 AM Chuck Lever <cel@kernel.org> wrote:
> > >
> > > From: Chuck Lever <chuck.lever@oracle.com>
> > >
> > > An NFSv4 client that sets an ACL with a named principal during file
> > > creation retrieves the ACL afterwards, and finds that it is only a
> > > default ACL (based on the mode bits) and not the ACL that was
> > > requested during file creation. This violates RFC 8881 section
> > > 6.4.1.3: "the ACL attribute is set as given".
> > >
> > > The issue occurs in nfsd_create_setattr(), which calls
> > > nfsd_attrs_valid() to determine whether to call nfsd_setattr().
> > > However, nfsd_attrs_valid() checks only for iattr changes and
> > > security labels, but not POSIX ACLs. When only an ACL is present,
> > > the function returns false, nfsd_setattr() is skipped, and the
> > > POSIX ACL is never applied to the inode.
> > >
> > > Subsequently, when the client retrieves the ACL, the server finds
> > > no POSIX ACL on the inode and returns one generated from the file's
> > > mode bits rather than returning the originally-specified ACL.
> > >
> > > Reported-by: Aurélien Couderc <aurelien.couderc2002@gmail.com>
> > > Fixes: c0cbe70742f4 ("NFSD: add posix ACLs to struct nfsd_attrs")
> > > Cc: Roland Mainz <roland.mainz@nrubsig.org>
> > > X-Cc: stable@vger.kernel.org
> > > Signed-off-by: Chuck Lever <cel@kernel.org>
> >
> > As said the patch works, but are there any tests in the Linux NFS
> > testsuite which cover ACLs with multiple users and groups, at OPEN and
> > SETATTR time?
>
> I developed several new pynfs [1] tests while troubleshooting this
> issue. I'll post them soon.

Thank you

My point however was if pynfs can take a list of users@domain,
groups@domain as input parameters, which are then used for
FATTR4_OWNER, FATTR4_OWNER_GROUP, FATTR4_ACL and FATTR4_DACL tests.

Some of the ACL issues only happen for specific ACL combinations, thus
such two lists with parameter input would be useful.

Aurélien
-- 
Aurélien Couderc <aurelien.couderc2002@gmail.com>
Big Data/Data mining expert, chess enthusiast

Re: [PATCH v1] NFSD: NFSv4 file creation neglects setting ACL

[Chuck Lever]

On Thu, Nov 27, 2025, at 4:12 PM, Aurélien Couderc wrote:
> On Sun, Nov 23, 2025 at 4:46 PM Chuck Lever <cel@kernel.org> wrote:
>>
>> On Sun, Nov 23, 2025 at 03:54:48PM +0100, Aurélien Couderc wrote:
>> > On Wed, Nov 19, 2025 at 1:51 AM Chuck Lever <cel@kernel.org> wrote:
>> > >
>> > > From: Chuck Lever <chuck.lever@oracle.com>
>> > >
>> > > An NFSv4 client that sets an ACL with a named principal during file
>> > > creation retrieves the ACL afterwards, and finds that it is only a
>> > > default ACL (based on the mode bits) and not the ACL that was
>> > > requested during file creation. This violates RFC 8881 section
>> > > 6.4.1.3: "the ACL attribute is set as given".
>> > >
>> > > The issue occurs in nfsd_create_setattr(), which calls
>> > > nfsd_attrs_valid() to determine whether to call nfsd_setattr().
>> > > However, nfsd_attrs_valid() checks only for iattr changes and
>> > > security labels, but not POSIX ACLs. When only an ACL is present,
>> > > the function returns false, nfsd_setattr() is skipped, and the
>> > > POSIX ACL is never applied to the inode.
>> > >
>> > > Subsequently, when the client retrieves the ACL, the server finds
>> > > no POSIX ACL on the inode and returns one generated from the file's
>> > > mode bits rather than returning the originally-specified ACL.
>> > >
>> > > Reported-by: Aurélien Couderc <aurelien.couderc2002@gmail.com>
>> > > Fixes: c0cbe70742f4 ("NFSD: add posix ACLs to struct nfsd_attrs")
>> > > Cc: Roland Mainz <roland.mainz@nrubsig.org>
>> > > X-Cc: stable@vger.kernel.org
>> > > Signed-off-by: Chuck Lever <cel@kernel.org>
>> >
>> > As said the patch works, but are there any tests in the Linux NFS
>> > testsuite which cover ACLs with multiple users and groups, at OPEN and
>> > SETATTR time?
>>
>> I developed several new pynfs [1] tests while troubleshooting this
>> issue. I'll post them soon.
>
> Thank you
>
> My point however was if pynfs can take a list of users@domain,
> groups@domain as input parameters, which are then used for
> FATTR4_OWNER, FATTR4_OWNER_GROUP, FATTR4_ACL and FATTR4_DACL tests.

pynfs tests are not parametrized, but we can choose specific
combinations of arguments to exercise, and then add a new test
for each of those cases.


> Some of the ACL issues only happen for specific ACL combinations, thus
> such two lists with parameter input would be useful.

I have additional pynfs tests which aren't quite ready yet that
exercise the relationship between OWNER@, GROUP@, and named
principals.

There are some complications with the NFSv4 <-> POSIX translation
adding a DENY ACE when it doesn't recognize that a named principal
is the same as OWNER@ or GROUP@. In that specific case a user can
set an ACL that locks the file owner out of the file unintentionally.


-- 
Chuck Lever

Re: [PATCH v1] NFSD: NFSv4 file creation neglects setting ACL

[Aurélien Couderc]

On Fri, Nov 28, 2025 at 4:44 PM Chuck Lever <cel@kernel.org> wrote:
>
>
>
> On Thu, Nov 27, 2025, at 4:12 PM, Aurélien Couderc wrote:
> > On Sun, Nov 23, 2025 at 4:46 PM Chuck Lever <cel@kernel.org> wrote:
> >>
> >> On Sun, Nov 23, 2025 at 03:54:48PM +0100, Aurélien Couderc wrote:
> >> > On Wed, Nov 19, 2025 at 1:51 AM Chuck Lever <cel@kernel.org> wrote:
> >> > >
> >> > > From: Chuck Lever <chuck.lever@oracle.com>
> >> > >
> >> > > An NFSv4 client that sets an ACL with a named principal during file
> >> > > creation retrieves the ACL afterwards, and finds that it is only a
> >> > > default ACL (based on the mode bits) and not the ACL that was
> >> > > requested during file creation. This violates RFC 8881 section
> >> > > 6.4.1.3: "the ACL attribute is set as given".
> >> > >
> >> > > The issue occurs in nfsd_create_setattr(), which calls
> >> > > nfsd_attrs_valid() to determine whether to call nfsd_setattr().
> >> > > However, nfsd_attrs_valid() checks only for iattr changes and
> >> > > security labels, but not POSIX ACLs. When only an ACL is present,
> >> > > the function returns false, nfsd_setattr() is skipped, and the
> >> > > POSIX ACL is never applied to the inode.
> >> > >
> >> > > Subsequently, when the client retrieves the ACL, the server finds
> >> > > no POSIX ACL on the inode and returns one generated from the file's
> >> > > mode bits rather than returning the originally-specified ACL.
> >> > >
> >> > > Reported-by: Aurélien Couderc <aurelien.couderc2002@gmail.com>
> >> > > Fixes: c0cbe70742f4 ("NFSD: add posix ACLs to struct nfsd_attrs")
> >> > > Cc: Roland Mainz <roland.mainz@nrubsig.org>
> >> > > X-Cc: stable@vger.kernel.org
> >> > > Signed-off-by: Chuck Lever <cel@kernel.org>
> >> >
> >> > As said the patch works, but are there any tests in the Linux NFS
> >> > testsuite which cover ACLs with multiple users and groups, at OPEN and
> >> > SETATTR time?
> >>
> >> I developed several new pynfs [1] tests while troubleshooting this
> >> issue. I'll post them soon.
> >
> > Thank you
> >
> > My point however was if pynfs can take a list of users@domain,
> > groups@domain as input parameters, which are then used for
> > FATTR4_OWNER, FATTR4_OWNER_GROUP, FATTR4_ACL and FATTR4_DACL tests.
>
> pynfs tests are not parametrized, but we can choose specific
> combinations of arguments to exercise, and then add a new test
> for each of those cases.

OK. But this is a SEVERE and gaping black hole in the test coverage,
because it prevents pynfs from properly testing FATTR4_OWNER,
FATTR4_OWNER_GROUP, FATTR4_ACL and FATTR4_DACL.

I think there should be parameters like that, and defaults such as
pynfsuser1, pynfsuser2, pynfsgroup1 and pynfsgroup2

>
>
> > Some of the ACL issues only happen for specific ACL combinations, thus
> > such two lists with parameter input would be useful.
>
> I have additional pynfs tests which aren't quite ready yet that
> exercise the relationship between OWNER@, GROUP@, and named
> principals.
>
> There are some complications with the NFSv4 <-> POSIX translation
> adding a DENY ACE when it doesn't recognize that a named principal
> is the same as OWNER@ or GROUP@. In that specific case a user can
> set an ACL that locks the file owner out of the file unintentionally.

Shouldn't OWNER@, GROUP@ priorise going into the uid and gid fields?

Aurélien
-- 
Aurélien Couderc <aurelien.couderc2002@gmail.com>
Big Data/Data mining expert, chess enthusiast

Re: [PATCH v1] NFSD: NFSv4 file creation neglects setting ACL

[Aurélien Couderc]

On Wed, Nov 19, 2025 at 1:51 AM Chuck Lever <cel@kernel.org> wrote:
>
> From: Chuck Lever <chuck.lever@oracle.com>
>
> An NFSv4 client that sets an ACL with a named principal during file
> creation retrieves the ACL afterwards, and finds that it is only a
> default ACL (based on the mode bits) and not the ACL that was
> requested during file creation. This violates RFC 8881 section
> 6.4.1.3: "the ACL attribute is set as given".
>
> The issue occurs in nfsd_create_setattr(), which calls
> nfsd_attrs_valid() to determine whether to call nfsd_setattr().
> However, nfsd_attrs_valid() checks only for iattr changes and
> security labels, but not POSIX ACLs. When only an ACL is present,
> the function returns false, nfsd_setattr() is skipped, and the
> POSIX ACL is never applied to the inode.
>
> Subsequently, when the client retrieves the ACL, the server finds
> no POSIX ACL on the inode and returns one generated from the file's
> mode bits rather than returning the originally-specified ACL.
>
> Reported-by: Aurélien Couderc <aurelien.couderc2002@gmail.com>
> Fixes: c0cbe70742f4 ("NFSD: add posix ACLs to struct nfsd_attrs")
> Cc: Roland Mainz <roland.mainz@nrubsig.org>
> X-Cc: stable@vger.kernel.org
> Signed-off-by: Chuck Lever <cel@kernel.org>

stable@vger.kernel.org is in CC. When will this patch land in the
Linux 6.6 and 5.10 STABLE branches?

Aurélien
-- 
Aurélien Couderc <aurelien.couderc2002@gmail.com>
Big Data/Data mining expert, chess enthusiast

Re: [PATCH v1] NFSD: NFSv4 file creation neglects setting ACL

[Chuck Lever]

On Sat, Nov 29, 2025, at 2:57 AM, Aurélien Couderc wrote:
> On Wed, Nov 19, 2025 at 1:51 AM Chuck Lever <cel@kernel.org> wrote:
>>
>> From: Chuck Lever <chuck.lever@oracle.com>
>>
>> An NFSv4 client that sets an ACL with a named principal during file
>> creation retrieves the ACL afterwards, and finds that it is only a
>> default ACL (based on the mode bits) and not the ACL that was
>> requested during file creation. This violates RFC 8881 section
>> 6.4.1.3: "the ACL attribute is set as given".
>>
>> The issue occurs in nfsd_create_setattr(), which calls
>> nfsd_attrs_valid() to determine whether to call nfsd_setattr().
>> However, nfsd_attrs_valid() checks only for iattr changes and
>> security labels, but not POSIX ACLs. When only an ACL is present,
>> the function returns false, nfsd_setattr() is skipped, and the
>> POSIX ACL is never applied to the inode.
>>
>> Subsequently, when the client retrieves the ACL, the server finds
>> no POSIX ACL on the inode and returns one generated from the file's
>> mode bits rather than returning the originally-specified ACL.
>>
>> Reported-by: Aurélien Couderc <aurelien.couderc2002@gmail.com>
>> Fixes: c0cbe70742f4 ("NFSD: add posix ACLs to struct nfsd_attrs")
>> Cc: Roland Mainz <roland.mainz@nrubsig.org>
>> X-Cc: stable@vger.kernel.org
>> Signed-off-by: Chuck Lever <cel@kernel.org>
>
> stable@vger.kernel.org is in CC. When will this patch land in the
> Linux 6.6 and 5.10 STABLE branches?

I can't give an exact date, but I expect it will appear in the LTS
kernels in about 6-7 weeks, unless someone finds an issue with it.


-- 
Chuck Lever

Re: [PATCH v1] NFSD: NFSv4 file creation neglects setting ACL

[Aurélien Couderc]

On Sat, Nov 29, 2025 at 4:40 PM Chuck Lever <cel@kernel.org> wrote:
>
>
>
> On Sat, Nov 29, 2025, at 2:57 AM, Aurélien Couderc wrote:
> > On Wed, Nov 19, 2025 at 1:51 AM Chuck Lever <cel@kernel.org> wrote:
> >>
> >> From: Chuck Lever <chuck.lever@oracle.com>
> >>
> >> An NFSv4 client that sets an ACL with a named principal during file
> >> creation retrieves the ACL afterwards, and finds that it is only a
> >> default ACL (based on the mode bits) and not the ACL that was
> >> requested during file creation. This violates RFC 8881 section
> >> 6.4.1.3: "the ACL attribute is set as given".
> >>
> >> The issue occurs in nfsd_create_setattr(), which calls
> >> nfsd_attrs_valid() to determine whether to call nfsd_setattr().
> >> However, nfsd_attrs_valid() checks only for iattr changes and
> >> security labels, but not POSIX ACLs. When only an ACL is present,
> >> the function returns false, nfsd_setattr() is skipped, and the
> >> POSIX ACL is never applied to the inode.
> >>
> >> Subsequently, when the client retrieves the ACL, the server finds
> >> no POSIX ACL on the inode and returns one generated from the file's
> >> mode bits rather than returning the originally-specified ACL.
> >>
> >> Reported-by: Aurélien Couderc <aurelien.couderc2002@gmail.com>
> >> Fixes: c0cbe70742f4 ("NFSD: add posix ACLs to struct nfsd_attrs")
> >> Cc: Roland Mainz <roland.mainz@nrubsig.org>
> >> X-Cc: stable@vger.kernel.org
> >> Signed-off-by: Chuck Lever <cel@kernel.org>
> >
> > stable@vger.kernel.org is in CC. When will this patch land in the
> > Linux 6.6 and 5.10 STABLE branches?
>
> I can't give an exact date, but I expect it will appear in the LTS
> kernels in about 6-7 weeks, unless someone finds an issue with it.

Do you have a web link (URL) where the patch is in Linus's tree (Linux
git HEAD)?

Aurélien
-- 
Aurélien Couderc <aurelien.couderc2002@gmail.com>
Big Data/Data mining expert, chess enthusiast

Re: [PATCH v1] NFSD: NFSv4 file creation neglects setting ACL

[Chuck Lever]

On Sat, Nov 29, 2025, at 2:55 AM, Aurélien Couderc wrote:
> On Fri, Nov 28, 2025 at 4:44 PM Chuck Lever <cel@kernel.org> wrote:
>>
>>
>>
>> On Thu, Nov 27, 2025, at 4:12 PM, Aurélien Couderc wrote:
>> > On Sun, Nov 23, 2025 at 4:46 PM Chuck Lever <cel@kernel.org> wrote:
>> >>
>> >> On Sun, Nov 23, 2025 at 03:54:48PM +0100, Aurélien Couderc wrote:
>> >> > On Wed, Nov 19, 2025 at 1:51 AM Chuck Lever <cel@kernel.org> wrote:
>> >> > >
>> >> > > From: Chuck Lever <chuck.lever@oracle.com>
>> >> > >
>> >> > > An NFSv4 client that sets an ACL with a named principal during file
>> >> > > creation retrieves the ACL afterwards, and finds that it is only a
>> >> > > default ACL (based on the mode bits) and not the ACL that was
>> >> > > requested during file creation. This violates RFC 8881 section
>> >> > > 6.4.1.3: "the ACL attribute is set as given".
>> >> > >
>> >> > > The issue occurs in nfsd_create_setattr(), which calls
>> >> > > nfsd_attrs_valid() to determine whether to call nfsd_setattr().
>> >> > > However, nfsd_attrs_valid() checks only for iattr changes and
>> >> > > security labels, but not POSIX ACLs. When only an ACL is present,
>> >> > > the function returns false, nfsd_setattr() is skipped, and the
>> >> > > POSIX ACL is never applied to the inode.
>> >> > >
>> >> > > Subsequently, when the client retrieves the ACL, the server finds
>> >> > > no POSIX ACL on the inode and returns one generated from the file's
>> >> > > mode bits rather than returning the originally-specified ACL.
>> >> > >
>> >> > > Reported-by: Aurélien Couderc <aurelien.couderc2002@gmail.com>
>> >> > > Fixes: c0cbe70742f4 ("NFSD: add posix ACLs to struct nfsd_attrs")
>> >> > > Cc: Roland Mainz <roland.mainz@nrubsig.org>
>> >> > > X-Cc: stable@vger.kernel.org
>> >> > > Signed-off-by: Chuck Lever <cel@kernel.org>
>> >> >
>> >> > As said the patch works, but are there any tests in the Linux NFS
>> >> > testsuite which cover ACLs with multiple users and groups, at OPEN and
>> >> > SETATTR time?
>> >>
>> >> I developed several new pynfs [1] tests while troubleshooting this
>> >> issue. I'll post them soon.
>> >
>> > Thank you
>> >
>> > My point however was if pynfs can take a list of users@domain,
>> > groups@domain as input parameters, which are then used for
>> > FATTR4_OWNER, FATTR4_OWNER_GROUP, FATTR4_ACL and FATTR4_DACL tests.
>>
>> pynfs tests are not parametrized, but we can choose specific
>> combinations of arguments to exercise, and then add a new test
>> for each of those cases.
>
> OK. But this is a SEVERE and gaping black hole in the test coverage,
> because it prevents pynfs from properly testing FATTR4_OWNER,
> FATTR4_OWNER_GROUP, FATTR4_ACL and FATTR4_DACL.

Keep in mind that pynfs is a unit test suite meant to exercise
/basic/ NFS protocol behavior. Each unit test is typically just
as simple as it can be written. [1]

If we want parametrized tests that exercise the more advanced
features of ACLs, then IMHO that is not "unit testing", and
therefore it lies outside the scope of pynfs.

Generally large deployments build their own test suites that
target the specific features they need. There is nothing
stopping you from creating a suite of tests specific to NFSv4
ACLs <nudge nudge>. 

Above, I see that you have included FATTR4_OWNER and
FATTR4_GROUP. What kind of interactions with ACL/DACL are you
thinking need to be explored?


> I think there should be parameters like that, and defaults such as
> pynfsuser1, pynfsuser2, pynfsgroup1 and pynfsgroup2

The new tests I've written (but haven't posted yet) use values
very much like your example defaults.


>> > Some of the ACL issues only happen for specific ACL combinations, thus
>> > such two lists with parameter input would be useful.
>>
>> I have additional pynfs tests which aren't quite ready yet that
>> exercise the relationship between OWNER@, GROUP@, and named
>> principals.
>>
>> There are some complications with the NFSv4 <-> POSIX translation
>> adding a DENY ACE when it doesn't recognize that a named principal
>> is the same as OWNER@ or GROUP@. In that specific case a user can
>> set an ACL that locks the file owner out of the file unintentionally.
>
> Shouldn't OWNER@, GROUP@ priorise going into the uid and gid fields?

Can you elaborate on that?


-- 
Chuck Lever

[1] https://en.wikipedia.org/wiki/Unit_testing#Unit

Re: [PATCH v1] NFSD: NFSv4 file creation neglects setting ACL

[Chuck Lever]

On Sat, Nov 29, 2025, at 10:49 AM, Aurélien Couderc wrote:
> On Sat, Nov 29, 2025 at 4:40 PM Chuck Lever <cel@kernel.org> wrote:
>>
>>
>>
>> On Sat, Nov 29, 2025, at 2:57 AM, Aurélien Couderc wrote:
>> > On Wed, Nov 19, 2025 at 1:51 AM Chuck Lever <cel@kernel.org> wrote:
>> >>
>> >> From: Chuck Lever <chuck.lever@oracle.com>
>> >>
>> >> An NFSv4 client that sets an ACL with a named principal during file
>> >> creation retrieves the ACL afterwards, and finds that it is only a
>> >> default ACL (based on the mode bits) and not the ACL that was
>> >> requested during file creation. This violates RFC 8881 section
>> >> 6.4.1.3: "the ACL attribute is set as given".
>> >>
>> >> The issue occurs in nfsd_create_setattr(), which calls
>> >> nfsd_attrs_valid() to determine whether to call nfsd_setattr().
>> >> However, nfsd_attrs_valid() checks only for iattr changes and
>> >> security labels, but not POSIX ACLs. When only an ACL is present,
>> >> the function returns false, nfsd_setattr() is skipped, and the
>> >> POSIX ACL is never applied to the inode.
>> >>
>> >> Subsequently, when the client retrieves the ACL, the server finds
>> >> no POSIX ACL on the inode and returns one generated from the file's
>> >> mode bits rather than returning the originally-specified ACL.
>> >>
>> >> Reported-by: Aurélien Couderc <aurelien.couderc2002@gmail.com>
>> >> Fixes: c0cbe70742f4 ("NFSD: add posix ACLs to struct nfsd_attrs")
>> >> Cc: Roland Mainz <roland.mainz@nrubsig.org>
>> >> X-Cc: stable@vger.kernel.org
>> >> Signed-off-by: Chuck Lever <cel@kernel.org>
>> >
>> > stable@vger.kernel.org is in CC. When will this patch land in the
>> > Linux 6.6 and 5.10 STABLE branches?
>>
>> I can't give an exact date, but I expect it will appear in the LTS
>> kernels in about 6-7 weeks, unless someone finds an issue with it.
>
> Do you have a web link (URL) where the patch is in Linus's tree (Linux
> git HEAD)?

It hasn't been merged yet, so it isn't in Linus' tree at the moment.


-- 
Chuck Lever

Re: [PATCH v1] NFSD: NFSv4 file creation neglects setting ACL

[Aurélien Couderc]

Is there any target date when this will land in Linux main tree, and
when will this land in the Linux 6.6 LTS tree?

Aurélien

On Sat, Nov 29, 2025 at 5:16 PM Chuck Lever <cel@kernel.org> wrote:
>
>
>
> On Sat, Nov 29, 2025, at 10:49 AM, Aurélien Couderc wrote:
> > On Sat, Nov 29, 2025 at 4:40 PM Chuck Lever <cel@kernel.org> wrote:
> >>
> >>
> >>
> >> On Sat, Nov 29, 2025, at 2:57 AM, Aurélien Couderc wrote:
> >> > On Wed, Nov 19, 2025 at 1:51 AM Chuck Lever <cel@kernel.org> wrote:
> >> >>
> >> >> From: Chuck Lever <chuck.lever@oracle.com>
> >> >>
> >> >> An NFSv4 client that sets an ACL with a named principal during file
> >> >> creation retrieves the ACL afterwards, and finds that it is only a
> >> >> default ACL (based on the mode bits) and not the ACL that was
> >> >> requested during file creation. This violates RFC 8881 section
> >> >> 6.4.1.3: "the ACL attribute is set as given".
> >> >>
> >> >> The issue occurs in nfsd_create_setattr(), which calls
> >> >> nfsd_attrs_valid() to determine whether to call nfsd_setattr().
> >> >> However, nfsd_attrs_valid() checks only for iattr changes and
> >> >> security labels, but not POSIX ACLs. When only an ACL is present,
> >> >> the function returns false, nfsd_setattr() is skipped, and the
> >> >> POSIX ACL is never applied to the inode.
> >> >>
> >> >> Subsequently, when the client retrieves the ACL, the server finds
> >> >> no POSIX ACL on the inode and returns one generated from the file's
> >> >> mode bits rather than returning the originally-specified ACL.
> >> >>
> >> >> Reported-by: Aurélien Couderc <aurelien.couderc2002@gmail.com>
> >> >> Fixes: c0cbe70742f4 ("NFSD: add posix ACLs to struct nfsd_attrs")
> >> >> Cc: Roland Mainz <roland.mainz@nrubsig.org>
> >> >> X-Cc: stable@vger.kernel.org
> >> >> Signed-off-by: Chuck Lever <cel@kernel.org>
> >> >
> >> > stable@vger.kernel.org is in CC. When will this patch land in the
> >> > Linux 6.6 and 5.10 STABLE branches?
> >>
> >> I can't give an exact date, but I expect it will appear in the LTS
> >> kernels in about 6-7 weeks, unless someone finds an issue with it.
> >
> > Do you have a web link (URL) where the patch is in Linus's tree (Linux
> > git HEAD)?
>
> It hasn't been merged yet, so it isn't in Linus' tree at the moment.
>
>
> --
> Chuck Lever



-- 
Aurélien Couderc <aurelien.couderc2002@gmail.com>
Big Data/Data mining expert, chess enthusiast

pynfs tests for set-acl-on-file/dir/dev creation time? Re: [PATCH v1] NFSD: NFSv4 file creation neglects setting ACL

[Aurélien Couderc]

On Sun, Nov 23, 2025 at 4:46 PM Chuck Lever <cel@kernel.org> wrote:
>
> On Sun, Nov 23, 2025 at 03:54:48PM +0100, Aurélien Couderc wrote:
> > On Wed, Nov 19, 2025 at 1:51 AM Chuck Lever <cel@kernel.org> wrote:
> > >
> > > From: Chuck Lever <chuck.lever@oracle.com>
> > >
> > > An NFSv4 client that sets an ACL with a named principal during file
> > > creation retrieves the ACL afterwards, and finds that it is only a
> > > default ACL (based on the mode bits) and not the ACL that was
> > > requested during file creation. This violates RFC 8881 section
> > > 6.4.1.3: "the ACL attribute is set as given".
> > >
> > > The issue occurs in nfsd_create_setattr(), which calls
> > > nfsd_attrs_valid() to determine whether to call nfsd_setattr().
> > > However, nfsd_attrs_valid() checks only for iattr changes and
> > > security labels, but not POSIX ACLs. When only an ACL is present,
> > > the function returns false, nfsd_setattr() is skipped, and the
> > > POSIX ACL is never applied to the inode.
> > >
> > > Subsequently, when the client retrieves the ACL, the server finds
> > > no POSIX ACL on the inode and returns one generated from the file's
> > > mode bits rather than returning the originally-specified ACL.
> > >
> > > Reported-by: Aurélien Couderc <aurelien.couderc2002@gmail.com>
> > > Fixes: c0cbe70742f4 ("NFSD: add posix ACLs to struct nfsd_attrs")
> > > Cc: Roland Mainz <roland.mainz@nrubsig.org>
> > > X-Cc: stable@vger.kernel.org
> > > Signed-off-by: Chuck Lever <cel@kernel.org>
> >
> > As said the patch works, but are there any tests in the Linux NFS
> > testsuite which cover ACLs with multiple users and groups, at OPEN and
> > SETATTR time?
>
> I developed several new pynfs [1] tests while troubleshooting this
> issue. I'll post them soon.
>
> --
> Chuck Lever
>
> [1] git://git.linux-nfs.org/projects/cdmackay/pynfs.git

https://git.linux-nfs.org/?p=cdmackay/pynfs.git;a=summary was not
updated since 10 months. Are the patches stuck, or something else
happened

Aurélien
-- 
Aurélien Couderc <aurelien.couderc2002@gmail.com>
Big Data/Data mining expert, chess enthusiast

Re: pynfs tests for set-acl-on-file/dir/dev creation time? Re: [PATCH v1] NFSD: NFSv4 file creation neglects setting ACL

[Calum Mackay]

Apologies; I have a number of patches queued up that I need to push out. 
Will do that asap.

best wishes,
calum.

On 01/03/2026 12:29 pm, Aurélien Couderc wrote:
> On Sun, Nov 23, 2025 at 4:46 PM Chuck Lever <cel@kernel.org> wrote:
>>
>> On Sun, Nov 23, 2025 at 03:54:48PM +0100, Aurélien Couderc wrote:
>>> On Wed, Nov 19, 2025 at 1:51 AM Chuck Lever <cel@kernel.org> wrote:
>>>>
>>>> From: Chuck Lever <chuck.lever@oracle.com>
>>>>
>>>> An NFSv4 client that sets an ACL with a named principal during file
>>>> creation retrieves the ACL afterwards, and finds that it is only a
>>>> default ACL (based on the mode bits) and not the ACL that was
>>>> requested during file creation. This violates RFC 8881 section
>>>> 6.4.1.3: "the ACL attribute is set as given".
>>>>
>>>> The issue occurs in nfsd_create_setattr(), which calls
>>>> nfsd_attrs_valid() to determine whether to call nfsd_setattr().
>>>> However, nfsd_attrs_valid() checks only for iattr changes and
>>>> security labels, but not POSIX ACLs. When only an ACL is present,
>>>> the function returns false, nfsd_setattr() is skipped, and the
>>>> POSIX ACL is never applied to the inode.
>>>>
>>>> Subsequently, when the client retrieves the ACL, the server finds
>>>> no POSIX ACL on the inode and returns one generated from the file's
>>>> mode bits rather than returning the originally-specified ACL.
>>>>
>>>> Reported-by: Aurélien Couderc <aurelien.couderc2002@gmail.com>
>>>> Fixes: c0cbe70742f4 ("NFSD: add posix ACLs to struct nfsd_attrs")
>>>> Cc: Roland Mainz <roland.mainz@nrubsig.org>
>>>> X-Cc: stable@vger.kernel.org
>>>> Signed-off-by: Chuck Lever <cel@kernel.org>
>>>
>>> As said the patch works, but are there any tests in the Linux NFS
>>> testsuite which cover ACLs with multiple users and groups, at OPEN and
>>> SETATTR time?
>>
>> I developed several new pynfs [1] tests while troubleshooting this
>> issue. I'll post them soon.
>>
>> --
>> Chuck Lever
>>
>> [1] git://git.linux-nfs.org/projects/cdmackay/pynfs.git
> 
> https://git.linux-nfs.org/?p=cdmackay/pynfs.git;a=summary was not
> updated since 10 months. Are the patches stuck, or something else
> happened
> 
> Aurélien

Re: pynfs tests for set-acl-on-file/dir/dev creation time? Re: [PATCH v1] NFSD: NFSv4 file creation neglects setting ACL

[Aurélien Couderc]

https://git.linux-nfs.org/?p=cdmackay/pynfs.git;a=summary appears to
be down at the moment. Could you please post the URL of the commits
once the site is up again?

Aurélien

On Wed, Mar 11, 2026 at 10:36 PM Calum Mackay <calum.mackay@oracle.com> wrote:
>
> Apologies; I have a number of patches queued up that I need to push out.
> Will do that asap.
>
> best wishes,
> calum.
>
> On 01/03/2026 12:29 pm, Aurélien Couderc wrote:
> > On Sun, Nov 23, 2025 at 4:46 PM Chuck Lever <cel@kernel.org> wrote:
> >>
> >> On Sun, Nov 23, 2025 at 03:54:48PM +0100, Aurélien Couderc wrote:
> >>> On Wed, Nov 19, 2025 at 1:51 AM Chuck Lever <cel@kernel.org> wrote:
> >>>>
> >>>> From: Chuck Lever <chuck.lever@oracle.com>
> >>>>
> >>>> An NFSv4 client that sets an ACL with a named principal during file
> >>>> creation retrieves the ACL afterwards, and finds that it is only a
> >>>> default ACL (based on the mode bits) and not the ACL that was
> >>>> requested during file creation. This violates RFC 8881 section
> >>>> 6.4.1.3: "the ACL attribute is set as given".
> >>>>
> >>>> The issue occurs in nfsd_create_setattr(), which calls
> >>>> nfsd_attrs_valid() to determine whether to call nfsd_setattr().
> >>>> However, nfsd_attrs_valid() checks only for iattr changes and
> >>>> security labels, but not POSIX ACLs. When only an ACL is present,
> >>>> the function returns false, nfsd_setattr() is skipped, and the
> >>>> POSIX ACL is never applied to the inode.
> >>>>
> >>>> Subsequently, when the client retrieves the ACL, the server finds
> >>>> no POSIX ACL on the inode and returns one generated from the file's
> >>>> mode bits rather than returning the originally-specified ACL.
> >>>>
> >>>> Reported-by: Aurélien Couderc <aurelien.couderc2002@gmail.com>
> >>>> Fixes: c0cbe70742f4 ("NFSD: add posix ACLs to struct nfsd_attrs")
> >>>> Cc: Roland Mainz <roland.mainz@nrubsig.org>
> >>>> X-Cc: stable@vger.kernel.org
> >>>> Signed-off-by: Chuck Lever <cel@kernel.org>
> >>>
> >>> As said the patch works, but are there any tests in the Linux NFS
> >>> testsuite which cover ACLs with multiple users and groups, at OPEN and
> >>> SETATTR time?
> >>
> >> I developed several new pynfs [1] tests while troubleshooting this
> >> issue. I'll post them soon.
> >>
> >> --
> >> Chuck Lever
> >>
> >> [1] git://git.linux-nfs.org/projects/cdmackay/pynfs.git
> >
> > https://git.linux-nfs.org/?p=cdmackay/pynfs.git;a=summary was not
> > updated since 10 months. Are the patches stuck, or something else
> > happened
> >
> > Aurélien
>
>


-- 
Aurélien Couderc <aurelien.couderc2002@gmail.com>
Big Data/Data mining expert, chess enthusiast

Re: pynfs tests for set-acl-on-file/dir/dev creation time? Re: [PATCH v1] NFSD: NFSv4 file creation neglects setting ACL

[Calum Mackay]

On 13/03/2026 7:48 am, Aurélien Couderc wrote:
> https://git.linux-nfs.org/?p=cdmackay/pynfs.git;a=summary appears to
> be down at the moment. Could you please post the URL of the commits
> once the site is up again?

hi Aurélien,

The site seems to be up at the moment, albeit rather slow to respond.

I don't look after the site itself, so I'm not sure if there are ongoing 
issues.

best wishes,
calum.

> 
> Aurélien
> 
> On Wed, Mar 11, 2026 at 10:36 PM Calum Mackay <calum.mackay@oracle.com> wrote:
>>
>> Apologies; I have a number of patches queued up that I need to push out.
>> Will do that asap.
>>
>> best wishes,
>> calum.
>>
>> On 01/03/2026 12:29 pm, Aurélien Couderc wrote:
>>> On Sun, Nov 23, 2025 at 4:46 PM Chuck Lever <cel@kernel.org> wrote:
>>>>
>>>> On Sun, Nov 23, 2025 at 03:54:48PM +0100, Aurélien Couderc wrote:
>>>>> On Wed, Nov 19, 2025 at 1:51 AM Chuck Lever <cel@kernel.org> wrote:
>>>>>>
>>>>>> From: Chuck Lever <chuck.lever@oracle.com>
>>>>>>
>>>>>> An NFSv4 client that sets an ACL with a named principal during file
>>>>>> creation retrieves the ACL afterwards, and finds that it is only a
>>>>>> default ACL (based on the mode bits) and not the ACL that was
>>>>>> requested during file creation. This violates RFC 8881 section
>>>>>> 6.4.1.3: "the ACL attribute is set as given".
>>>>>>
>>>>>> The issue occurs in nfsd_create_setattr(), which calls
>>>>>> nfsd_attrs_valid() to determine whether to call nfsd_setattr().
>>>>>> However, nfsd_attrs_valid() checks only for iattr changes and
>>>>>> security labels, but not POSIX ACLs. When only an ACL is present,
>>>>>> the function returns false, nfsd_setattr() is skipped, and the
>>>>>> POSIX ACL is never applied to the inode.
>>>>>>
>>>>>> Subsequently, when the client retrieves the ACL, the server finds
>>>>>> no POSIX ACL on the inode and returns one generated from the file's
>>>>>> mode bits rather than returning the originally-specified ACL.
>>>>>>
>>>>>> Reported-by: Aurélien Couderc <aurelien.couderc2002@gmail.com>
>>>>>> Fixes: c0cbe70742f4 ("NFSD: add posix ACLs to struct nfsd_attrs")
>>>>>> Cc: Roland Mainz <roland.mainz@nrubsig.org>
>>>>>> X-Cc: stable@vger.kernel.org
>>>>>> Signed-off-by: Chuck Lever <cel@kernel.org>
>>>>>
>>>>> As said the patch works, but are there any tests in the Linux NFS
>>>>> testsuite which cover ACLs with multiple users and groups, at OPEN and
>>>>> SETATTR time?
>>>>
>>>> I developed several new pynfs [1] tests while troubleshooting this
>>>> issue. I'll post them soon.
>>>>
>>>> --
>>>> Chuck Lever
>>>>
>>>> [1] git://git.linux-nfs.org/projects/cdmackay/pynfs.git
>>>
>>> https://git.linux-nfs.org/?p=cdmackay/pynfs.git;a=summary was not
>>> updated since 10 months. Are the patches stuck, or something else
>>> happened
>>>
>>> Aurélien
>>
>>
> 
> 

Re: pynfs tests for set-acl-on-file/dir/dev creation time? Re: [PATCH v1] NFSD: NFSv4 file creation neglects setting ACL

[Aurélien Couderc]

On Fri, Mar 13, 2026 at 8:28 PM Calum Mackay <calum.mackay@oracle.com> wrote:
>
> On 13/03/2026 7:48 am, Aurélien Couderc wrote:
> > https://git.linux-nfs.org/?p=cdmackay/pynfs.git;a=summary appears to
> > be down at the moment. Could you please post the URL of the commits
> > once the site is up again?
>
> hi Aurélien,
>
> The site seems to be up at the moment, albeit rather slow to respond.
>
> I don't look after the site itself, so I'm not sure if there are ongoing
> issues.

It works again for me, but there are no new changes for 2026. Did you
push your patches?

Aurélien
-- 
Aurélien Couderc <aurelien.couderc2002@gmail.com>
Big Data/Data mining expert, chess enthusiast

Re: pynfs tests for set-acl-on-file/dir/dev creation time? Re: [PATCH v1] NFSD: NFSv4 file creation neglects setting ACL

[Calum Mackay]

On 15/03/2026 8:33 am, Aurélien Couderc wrote:
> On Fri, Mar 13, 2026 at 8:28 PM Calum Mackay <calum.mackay@oracle.com> wrote:
>>
>> On 13/03/2026 7:48 am, Aurélien Couderc wrote:
>>> https://git.linux-nfs.org/?p=cdmackay/pynfs.git;a=summary appears to
>>> be down at the moment. Could you please post the URL of the commits
>>> once the site is up again?
>>
>> hi Aurélien,
>>
>> The site seems to be up at the moment, albeit rather slow to respond.
>>
>> I don't look after the site itself, so I'm not sure if there are ongoing
>> issues.
> 
> It works again for me, but there are no new changes for 2026. Did you
> push your patches?
Not yet, but I will soon, hopefully this week.

thanks,
calum.