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: <41e9ed40-311d-42ee-9fe2-5af3ecda67d4@oracle.com>
Date: Tue, 29 Apr 2025 09:45:13 -0400
From: Chuck Lever <chuck.lever@...cle.com>
To: Sebastian Feld <sebastian.n.feld@...il.com>
Cc: 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 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.


-- 
Chuck Lever