linux-kernel - Re: fattr4_hidden and fattr4_system r/w attributes in Linux NFSD?

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: <CAHnbEGLuYq6vYqq9M3w+W0iR-r0OOeCfSD3cEV-yekAbo-yAQw@mail.gmail.com>
Date: Tue, 17 Jun 2025 09:59:53 +0200
From: Sebastian Feld <sebastian.n.feld@...il.com>
To: Linux NFS Mailing List <linux-nfs@...r.kernel.org>
Cc: open list <linux-kernel@...r.kernel.org>
Subject: Re: fattr4_hidden and fattr4_system r/w attributes in Linux NFSD?

On Tue, Apr 29, 2025 at 3:45 PM Chuck Lever <chuck.lever@...cle.com> wrote:
>
> On 4/29/25 9:10 AM, Sebastian Feld wrote:
> > On Mon, Apr 28, 2025 at 4:15 PM Chuck Lever <chuck.lever@...cle.com> wrote:
> >>
> >> Hi Sebastian -
> >>
> >> On 4/28/25 7:06 AM, Sebastian Feld wrote:
> >>> I've been debating with Opentext support about their Windows NFS4.0
> >>> client about a problem that the Windows attributes HIDDEN and SYSTEM
> >>> work with a Solaris NFSD, but not with a Linux NFSD.
> >>>
> >>> Their support said it's a known bug in LInux NFSD that "fattr4_hidden
> >>> and fattr4_system, specified in RFC 3530, are broken in Linux NFSD".
> >>
> >> RFC 7530 updates and replaces RFC 3530.
> >>
> >> Section 5.7 lists "hidden" and "system" as RECOMMENDED attributes,
> >> meaning that NFSv4 servers are not required to implement them.
> >>
> >> So that tells me that both the Solaris NFS server and the Linux NFS
> >> server are spec compliant in this regard. This is NOTABUG, but rather it
> >> is a server implementation choice that is permitted by RFC.
> >>
> >> It is more correct to say that the Linux NFS server does not currently
> >> implement either of these attributes. The reason is that native Linux
> >> file systems do not support these attributes, and I believe that neither
> >> does the Linux VFS. So there is nowhere to store these, and no way to
> >> access them in filesystems (such as the Linux port of NTFS) that do
> >> implement them.
> >>
> >> We want to have a facility that can be used by native applications
> >> (such as Wine), Samba, and NFSD. So implementing side-car storage
> >> for such attributes that only NFSD can see and use is not really
> >> desirable.
> >
> > I did a bit of digging, that debate started in 2002.
> >
> > 23 years later, nothing happened. No Solution.
> > Very depressing.
>
> It's a hard problem.
>
> Focus on the recent work. It appears to be promising and there have
> been few objections to it.

Do you have any reference to that work? Are there status updates?

Sebi
-- 
Sebastian Feld - IT security consultant