On 1/14/25 4:10 PM, Pali Rohár wrote:
On Saturday 04 January 2025 10:30:26 Chuck Lever wrote:
On 1/4/25 3:52 AM, Christian Brauner wrote:
On Thu, Jan 02, 2025 at 10:52:51AM -0500, Chuck Lever wrote:
On 1/2/25 9:37 AM, Jan Kara wrote:
Hello!
On Fri 27-12-24 13:15:08, Pali Rohár wrote:
Few months ago I discussed with Steve that Linux SMB client has some
problems during removal of directory which has read-only attribute set.
I was looking what exactly the read-only windows attribute means, how it
is interpreted by Linux and in my opinion it is wrongly used in Linux at
all.
Windows filesystems NTFS and ReFS, and also exported over SMB supports
two ways how to present some file or directory as read-only. First
option is by setting ACL permissions (for particular or all users) to
GENERIC_READ-only. Second option is by setting the read-only attribute.
Second option is available also for (ex)FAT filesystems (first option via
ACL is not possible on (ex)FAT as it does not have ACLs).
First option (ACL) is basically same as clearing all "w" bits in mode
and ACL (if present) on Linux. It enforces security permission behavior.
Note that if the parent directory grants for user delete child
permission then the file can be deleted. This behavior is same for Linux
and Windows (on Windows there is separate ACL for delete child, on Linux
it is part of directory's write permission).
Second option (Windows read-only attribute) means that the file/dir
cannot be opened in write mode, its metadata attribute cannot be changed
and the file/dir cannot be deleted at all. But anybody who has
WRITE_ATTRIBUTES ACL permission can clear this attribute and do whatever
wants.
I guess someone with more experience how to fuse together Windows & Linux
permission semantics should chime in here but here are my thoughts.
Linux filesystems has similar thing to Windows read-only attribute
(FILE_ATTRIBUTE_READONLY). It is "immutable" bit (FS_IMMUTABLE_FL),
which can be set by the "chattr" tool. Seems that the only difference
between Windows read-only and Linux immutable is that on Linux only
process with CAP_LINUX_IMMUTABLE can set or clear this bit. On Windows
it can be anybody who has write ACL.
Now I'm thinking, how should be Windows read-only bit interpreted by
Linux filesystems drivers (FAT, exFAT, NTFS, SMB)? I see few options:
0) Simply ignored. Disadvantage is that over network fs, user would not
be able to do modify or delete such file, even as root.
1) Smartly ignored. Meaning that for local fs, it is ignored and for
network fs it has to be cleared before any write/modify/delete
operation.
2) Translated to Linux mode/ACL. So the user has some ability to see it
or change it via chmod. Disadvantage is that it mix ACL/mode.
So this option looks sensible to me. We clear all write permissions in
file's mode / ACL. For reading that is fully compatible, for mode
modifications it gets a bit messy (probably I'd suggest to just clear
FILE_ATTRIBUTE_READONLY on modification) but kind of close.
IMO Linux should store the Windows-specific attribute information but
otherwise ignore it. Modifying ACLs based seems like a road to despair.
Plus there's no ACL representation for OFFLINE and some of the other
items that we'd like to be able to support.
If I were king-for-a-day (tm) I would create a system xattr namespace
just for these items, and provide a VFS/statx API for consumers like
Samba, ksmbd, and knfsd to set and get these items. Each local
filesystem can then implement storage with either the xattr or (eg,
ntfs) can store them directly.
Introducing a new xattr namespace for this wouldn't be a problem imho.
Why would this need a new statx() extension though? Wouldn't the regular
xattr apis to set and get xattrs be enough?
My thought was to have a consistent API to access these attributes, and
let the filesystem implementers decide how they want to store them. The
Linux implementation of ntfs, for example, probably wants to store these
on disk in a way that is compatible with the Windows implementation of
NTFS.
A common API would mean that consumers (like NFSD) wouldn't have to know
those details.
--
Chuck Lever
So, what about introducing new xattrs for every attribute with this pattern?
system.attr.readonly
system.attr.hidden
system.attr.system
system.attr.archive
system.attr.temporary
system.attr.offline
system.attr.not_content_indexed
Yes, all of them could be stored as xattrs for file systems that do
not already support these attributes.
But I think we don't want to expose them directly to users, however.
Some file systems, like NTFS, might want to store these on-disk in a way
that is compatible with Windows.
So I think we want to create statx APIs for consumers like user space
and knfsd, who do not care to know the specifics of how this information
is stored by each file system.
The xattrs would be for file systems that do not already have a way to
represent this information in their on-disk format.
All those attributes can be set by user, I took names from SMB, which
matches NTFS and which subsets are used by other filesystems like FAT,
exFAT, NFS4, UDF, ...
Every xattr would be in system.attr namespace and would contain either
value 0 or 1 based on that fact if is set or unset. If the filesystem
does not support particular attribute then xattr get/set would return
error that it does not exist.
Or, if the xattr exists, then that means the equivalent Windows
attribute is asserted; and if it does not, the equivalent Windows
attribute is clear. But again, I think each file system should be
able to choose how they implement these, and that implementation is
then hidden by statx.
This would be possible to use by existing userspace getfattr/setfattr
tools and also by knfsd/ksmbd via accessing xattrs directly.
--
Chuck Lever
