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-next>] [day] [month] [year] [list]

Message-ID: <CAHnbEGJq-w4CMS1dg8UBraV+6kLMkmC-hO4Dq7f4z8Af6maitA@mail.gmail.com>
Date: Tue, 29 Apr 2025 15:10:08 +0200
From: Sebastian Feld <sebastian.n.feld@...il.com>
To: Linux NFS Mailing List <linux-nfs@...r.kernel.org>, open list <linux-kernel@...r.kernel.org>
Subject: Re: fattr4_hidden and fattr4_system r/w attributes in Linux NFSD?

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.

Sebi
-- 
Sebastian Feld - IT security consultant