On 5/5/2025 10:02 AM, Etienne Champetier wrote:
Hello,Removing lists, feel free to add them back Le lun. 5 mai 2025 à 09:14, Christian Brauner <brau...@kernel.org> a écrit :Why is it removed? That's a very strange comment: #if 0 /* reportedly no longer needed */ So then just don't remove it. I don't see a reason for us to workaround userspace creating a bug for itself and forcing us to add two new inode operations to work around it.This bash workaround introduced ages ago for AFS bypass fs.protected_regular
Chet, I don't think this history is correct. The bash workaround was introduced in 1992 to workaround a behavior when appending to restricted access directories stored in IBM AFS 3.1[1] and the Linux kernel's 30aba6656f61ed44cba445a3c0d38b296fa9e8f5 wasn't added until 2018.
IBM AFS 3.2 addressed the narrow use case described by the bug report by implementing a potentially racy change to the AFS cache manager and failing to address the server side. However, that is out of scope for this discussion. To the extent that there is a bug in one or more of the AFS server implementations it should be fixed there.
The bash fallback logic to retry the open without O_CREAT introduces a bypass for the kernel mode protection provided by 30aba6656f61 and should be removed.
Christian,It just so happens that the workaround added to bash in 1992 masks an incompatibility introduced by 30aba6656f61 when the backing filesystem is "afs" because the ownership checks required by may_create_in_sticky() cannot be reliably performed based upon the kernel's local knowledge of the uids. Ownership checks in "afs" are performed by the fileserver's evaluation of the caller's rxgk or rxkad security tokens and not by use of uids. This incompatibility was only noticed after Red Hat began enabling fs.protected_regular by default and bash removed the fallback logic in the proposed 5.3 release candidates.
The proposed inode operations are to permit filesystems such as AFS which cannot rely upon the kernel's local uid knowledge to perform the required the ownership checks to perform those checks via another mechanism. In the case of AFS, the fileserver already conveys the answer to the "is inode owned by me?" question as part of its delivery of caller access rights (AFSFetchStatus.CallerAccess). The answer to the "do these two inodes have the same owner?" question can be determined via comparison of the AFSFetchStatus.Owner fields for each inode which belong to a uid namespace that is specific the the AFS cell in which the inodes are stored. When performing this ownership check for network filesystems I do not believe it is safe to assume that the uid namespace of the network filesystem is identical to the local machine's uid namespace. I think it would be safer for all network filesystems to answer the ownership questions using network uid values instead of local uid values when available.
I'm also concerned about using id-mapped values for this comparison because there is no restriction preventing two distinct id values from being mapped to the same id.
Sincerely, Jeffrey Altman [1] https://groups.google.com/g/gnu.bash.bug/c/6PPTfOgFdL4/m/2AQU-S1N76UJ
smime.p7s
Description: S/MIME Cryptographic Signature
