Problems with xattr / v2.1.6 Monterey (Intel)

[lundman]

Hey, thanks for the quick fix! So, I should try to compile the patched version... or will there be an "official" new version?

If you are comfortable to do so, compile it yourself and try. But once I have most of the issues bundled into this, I'll do
a RC release so people can test these fixes.

[lundman]

Extended Attributes
Supported by ZFS 2.1.6 and fastest if using the -xattr=sa option when creating a dataset.
Two Exceptions: com.apple.FinderInfo and com.apple.ResourceFork extended attributes that are empty (all 0) get dropped / ignored by ZFS 2.1.6.
(actually, it might be that any empty xattr gets dropped - I saw some empty 'com.apple.assetsd.title' attributes which I couldn't sync to ZFS 2.1.6.
On the other hand, on Ventura I can write an all-0 xattr as long as it is not com.apple.FinderInfo - only then this also fails on APFS)

Any old xattr can be all zeros:

Code: Select all

# xattr -wx "lundman" 000000 /Volumes/BOOM/test.txt
# xattr -l /Volumes/BOOM/test.txt                                                           
lundman:
00000000  00 00 00                                         |...|


but as you point out "com.apple.FinderInfo" is not allowed to be all zero. Based on:

/*
* By convention, Finder Info that is all zeroes is equivalent to not
* having a Finder Info EA. So if we're trying to set the Finder Info
* to all zeroes, then delete it instead. If a file didn't have an
* AppleDouble file before, this prevents creating an AppleDouble file
* with no useful content.
*
* If neither XATTR_CREATE nor XATTR_REPLACE were specified, we check
* for all zeroes Finder Info before opening the AppleDouble file.
* But if either of those options were specified, we need to open the
* AppleDouble file to see whether there was already Finder Info (so we
* can return an error if needed); this case is handled further below.
*
* NOTE: this copies the Finder Info data into the "finfo" local.
*/

and from hfs

* Make a copy of the cnode's finderinfo to a local so we can
* zero out the date added field. Also zero out the private type/creator
* for symlinks.

So possibly ZFS clears out too many fields? and accidentally make it all zero, then we remove it. The trick will be figuring out how much to actually
zero.

We clear it here:
https://github.com/openzfsonosx/openzfs ... 1843-L1879

[lundman]

Important: The Posix mapping of Apple resource forks to a special file path (FILENAME/..namedfork/rsrc) seems unsupported by ZFS 2.1.6, and any software trying to do so (e.g. Finder, or the Backup Bouncer scripts I reported above) fails.

We.. almost.. get this right

Code: Select all

# xattr -w "com.apple.ResourceFork" "Hello world\n" /Volumes/BOOM/test.txt

# cat /Volumes/BOOM/test.txt/..namedfork/rsrc
cat: /Volumes/BOOM/test.txt/..namedfork/rsrc: No such file or directory

<zfs`__dprintf (zfs_debug.c:250)> dprintf: zfs_vnops_osx.c:3829:zfs_vnop_getnamedstream(): +getnamedstream vp 0xffffff801e59f300 'com.apple.ResourceFork': op 0
<zfs`__dprintf (zfs_debug.c:250)> dprintf: zfs_znode.c:1087:zfs_zget_ext(): +zget 158
<zfs`__dprintf (zfs_debug.c:250)> dprintf: zfs_vnops_osx.c:3894:zfs_vnop_getnamedstream(): zfs_vnop_getnamedstream vp 0xffffff801e59f300: error 93


and with

Code: Select all

# sysctl kstat.zfs.darwin.tunable.zfs.xattr_compat=1
# xattr -w "com.apple.ResourceFork" "Hello world\n" /Volumes/BOOM/test.txt
# cat /Volumes/BOOM/test.txt/..namedfork/rsrc
cat: /Volumes/BOOM/test.txt/..namedfork/rsrc: Invalid argument
<zfs`__dprintf (zfs_debug.c:250)> dprintf: zfs_vnops_osx.c:3829:zfs_vnop_getnamedstream(): +getnamedstream vp 0xffffff801e59f300 'com.apple.ResourceFork': op 0


Oh right, i took it out

Code: Select all


#if 0 // Disabled, not sure its required and empty vnodes are odd.             
    /*                                                                         
     * If the lookup is NS_OPEN, they are accessing "..namedfork/rsrc"         
     * to which we should return 0 with empty vp to empty file.                 
     * See hfs_vnop_getnamedstream()                                           
     */


how important do we feel it is?

[lundman]

OK, turns out that we need to call vnode_update_identity( ....., VNODE_UPDATE_NAME); in zfs_vnop_getnamedstream()
since it returns a vnode outside of the "normal path" (where VFS has a name for it), and without a name, it gets rejected by
mac_vnode_check_open().

Code: Select all

# cat /Volumes/BOOM/test.txt/..namedfork/rsrc
Hello world\n#                                                                 


I need to cleanup the code and figure out how to get the "parent" name.

[lundman]

https://github.com/openzfsonosx/openzfs ... ec41735d76

Code: Select all

# touch /Volumes/BOOM/new.txt
# echo "Hello World" > /Volumes/BOOM/new.txt/..namedfork/rsrc
# cat /Volumes/BOOM/new.txt/..namedfork/rsrc
Hello World



[lundman]

ACL:

Code: Select all


# echo "Hello World" > /Volumes/BOOM/acltest.txt
# chown root /Volumes/BOOM/acltest.txt ; chmod 400 /Volumes/BOOM/acltest.txt
# sudo -u lundman cat /Volumes/BOOM/acltest.txt
cat: /Volumes/BOOM/acltest.txt: Permission denied
# chmod +a "lundman:allow:read" /Volumes/BOOM/acltest.txt
# sudo -u lundman cat /Volumes/BOOM/acltest.txt
cat: /Volumes/BOOM/acltest.txt: Permission denied
# ls -le /Volumes/BOOM/acltest.txt
-r--------  1 root  wheel  12 Feb 17 17:39 /Volumes/BOOM/acltest.txt


well, that's broken.

[roemer]

but as you point out "com.apple.FinderInfo" is not allowed to be all zero.
[...]
So possibly ZFS clears out too many fields? and accidentally make it all zero, then we remove it. The trick will be figuring out how much to actually
zero.

Indeed, this is tricky as it seems not well documented.
I experimented with APFS under macOS 13.2 and with ZFS 2.1.6:

Test 1: Zeroed and Empty Extended Attributes

Code: Select all

touch testfile-apfs
xattr -wx com.apple.ResourceFork 0000000000000000000000000000000000000000000000000000000000000000  testfile-apfs
xattr -wx com.apple.FinderInfo   0000000000000000000000000000000000000000000000000000000000000000  testfile-apfs
xattr -wx org.home.zeroattr      0000000000000000000000000000000000000000000000000000000000000000  testfile-apfs
xattr -w org.home.emptyattr      ""  testfile-apfs
ls -l@ testfile-apfs
-rw-r--r--@ 1 user  staff  0 18 Feb 13:16 testfile-apfs
   com.apple.ResourceFork   32
   org.home.emptyattr   0
   org.home.zeroattr   32
xattr -lx testfile-apfs
com.apple.ResourceFork:
00000000  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00000020
org.home.emptyattr:
00000000
org.home.zeroattr:
00000000  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00000020


Zeroed ResourceForks are possible, but note that the all-zero FinderInfo quitely gets dropped by APFS.
Also note that I can write an empty extended attribute as long as it is neither FinderInfo, nor ResourceFork.

ZFS 2.1.6 is consistent in not writing an all-zero FinderInfo, but it also does not allow any empty extended attribute, regardless of its name, which is more restrictive than APFS:

Code: Select all

touch testfile-zfs
xattr -wx com.apple.ResourceFork 0000000000000000000000000000000000000000000000000000000000000000  testfile-zfs
xattr -wx com.apple.FinderInfo   0000000000000000000000000000000000000000000000000000000000000000  testfile-zfs
xattr -wx org.home.zeroattr      0000000000000000000000000000000000000000000000000000000000000000  testfile-zfs
xattr -w org.home.emptyattr      ""  testfile-zfs
   xattr: [Errno 93] Attribute not found: 'testfile-zfs'
ls -l@ testfile-zfs
-rw-r--r--@ 1 user  wheel  0 18 Feb 13:12 testfile-zfs
   com.apple.ResourceFork   32
   org.home.zeroattr   32


Test 2: Masking of FinderInfo bytes
In APFS, at least with macOS 13.2, it seems to write the whole FinderInfo without masking, as long as it is non-empty and not all-zeros:

Code: Select all

touch testfile2-apfs
xattr -wx com.apple.FinderInfo   5445585431313131313131313131313131313131313131313131313131313131 testfile2-apfs
ls -l@ testfile2-apfs
-rw-r--r--@ 1 user  staff  0 18 Feb 13:21 testfile2-apfs
   com.apple.FinderInfo   32
xattr -lx testfile2-apfs
com.apple.FinderInfo:
00000000  54 45 58 54 31 31 31 31 31 31 31 31 31 31 31 31  |TEXT111111111111|
00000010  31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31  |1111111111111111|
00000020

This also works on symbolic links, and also note that symbolic links cannot have a resource fork:

Code: Select all

ln -s testfile2-apfs testlink-apfs
xattr -ws  org.home.attribute "00000000000000000000000000000000" testlink-apfs
xattr -wsx com.apple.FinderInfo   5445585431313131313131313131313131313131313131313131313131313131 testlink-apfs
xattr -ws  com.apple.ResourceFork "00000000000000000000000000000000" testlink-apfs                             
   xattr: [Errno 1] Operation not permitted: 'testlink-apfs'
ls -l@ testlink-apfs
lrwxr-xr-x@ 1 user  staff  14 18 Feb 13:31 testlink-apfs -> testfile2-apfs
   com.apple.FinderInfo   32
   org.home.attribute   32
xattr -lsx testlink-apfs
com.apple.FinderInfo:
00000000  54 45 58 54 31 31 31 31 31 31 31 31 31 31 31 31  |TEXT111111111111|
00000010  31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31  |1111111111111111|
00000020
org.home.attribute:
00000000  30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30  |0000000000000000|
00000010  30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30  |0000000000000000|
00000020


In contrast, ZFS 2.1.6 masks out several bytes in the extended FinderInfo structure (last 16 bytes):

Code: Select all

touch testfile2-zfs
xattr -wx com.apple.FinderInfo   5445585431313131313131313131313131313131313131313131313131313131 testfile2-zfs
ls -l@ testfile2-zfs
-rw-r--r--@ 1 user  wheel  0 18 Feb 13:26 testfile2-zfs
   com.apple.FinderInfo   32
xattr -lx testfile2-zfs
com.apple.FinderInfo:
00000000  54 45 58 54 31 31 31 31 31 31 31 31 31 31 31 31  |TEXT111111111111|
00000010  00 00 00 00 00 00 00 00 31 31 31 31 00 00 00 00  |........1111....|
00000020

For symbolic links, ZFS 2.1.6 masks out even more fields, including the fdType and fdCreator fields.
But then apparently to make up for this, it allows to create a ResourceFork xattr on the symbolic link

Code: Select all

ln -s testfile2-zfs testlink-zfs
xattr -ws  org.home.attribute "00000000000000000000000000000000" testlink-zfs
xattr -wsx com.apple.FinderInfo   5445585431313131313131313131313131313131313131313131313131313131 testlink-zfs
xattr -ws  com.apple.ResourceFork "00000000000000000000000000000000" testlink-zfs
ls -l@ testlink-zfs
lrwxr-xr-x@ 1 user  wheel  13 18 Feb 13:35 testlink-zfs -> testfile2-zfs
   org.home.attribute   32
   com.apple.FinderInfo   32
   com.apple.ResourceFork   32
xattr -lsx testlink-zfs
com.apple.FinderInfo:
00000000  00 00 00 00 00 00 00 00 31 31 31 31 31 31 31 31  |................|
00000010  00 00 00 00 00 00 00 00 31 31 31 31 00 00 00 00  |................|
00000020
org.home.attribute:
00000000  30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30  |0000000000000000|
00000010  30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30  |0000000000000000|
00000020
com.apple.ResourceFork:
00000000  30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30  |0000000000000000|
00000010  30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30  |0000000000000000|
00000020

Disclaimer: I am just observing and comparing the extended attribute behaviour from APFS and ZFS here; I do not claim to know the semantics of the FinderInfo, especially its extended part - and I haven't checked the hfs or apfs documentation from Apple... Also note that I checked on APFS, while the zfs code is referring to the hfs documentation.

[lundman]

Honestly, if we can skip the zeroing of finderinfo, I am quite happy to do so, and if apfs does, let us do the same! It should fix those things.

All-zero finderinfo to be removed still.

I'll check on that empty xattr not working.

[lundman]

https://github.com/openzfsonosx/openzfs ... 23fdce67f3

[roemer]

Thanks for the patch on ACLs, lundman!
You seem to really have a run at the moment

Regarding the earlier discussion about the changing of FinderInfo xattrs:
Would it be an idea to make this extended attribute behaviour dependent on the com.apple.mimic property of a dataset?
Like keeping all extended attribute unchanged if mimic is not set to hfs?