extended attributes and ACLs not handled correctly?

Developer discussions.

Re: extended attributes and ACLs not handled correctly?

Postby ilovezfs » Thu Apr 10, 2014 7:28 am

roemer wrote:Thanks for the link. So the rationale is pool-compatibility with Linux/Solaris.
In that discussion thread on Github, you pointed to the 'xattr_darwinacls' branch as potential alternative.
That branch was last modified about 4 months ago.
How is that branch kept up-to-date with bugfixes in the master branch?

Secondly, if I compile my own kernel extension from that branch, it is not signed and would hence create a warning at each boot from OS X 10.9?
Anyway to avoid this (other than paying 99 bucks/anno to Apple ;)


That branch would need to be rebased off of master. However, although I put that branch out there to appease those who are bothered by this, I do not particularly like that method. A "correct" method would implement an entirely separate ACL type for Darwin ACLs. Basically we'd need to spoof Darwin ACLs which are meant to only be "extras" above and beyond the mode, which is not entirely possible since Darwin ACLs can create situations that NFSv4 ACLs cannot, or we'd need to introduce a pool incompatibility, with a feature flag, or later, when there is OpenZFS support for it, a per dataset flag.

In my opinion, a separate Darwin ACL type is an extremely low priority item.

The best discussion of the difference between Darwin ACLs and NFSv4 ACLs is here:
https://wiki.freebsd.org/NFSv4_ACLs
___
When it's your own kext, compiled by you and unsigned, it should be installed to /System/Library/Extensions instead of /Library/Extensions, which is reserved for signed kexts. You only get that warning once and then it gets white-listed.
ilovezfs
 
Posts: 232
Joined: Thu Mar 06, 2014 7:58 am

Re: extended attributes and ACLs not handled correctly?

Postby roemer » Thu Apr 10, 2014 10:04 pm

Thanks for the response. I also found git's rebase command in the meanwhile, but as it prompts for manual action to fix clashes on zfs_acl.c, I tested with the original 'xattr_darwinacls' branch. I actually like its effect: In my (few) tests so far, zfs did preserve Mac ACLs correctly, even after a full round-trip HFS+ - ZFS - HFS+. I like this, as it gives me - from the user perspective - the confidence that the file system retains my data, including its metadata and permissions. As far as I can see, the intermediate usage of extended attributes to store the ACLs is kept hidden from users.

I understand that this is additional implementation work and hassle when trying to keep full pool compatibility with OpenZFS.
But as a file system user, I appreciate to be able to trust a system, even for features which I myself might not need every day.
Given that I anticipate only few ACLs making it into my ZFS pool, typically in form of application bundles as part of my SoftwareArchive, I am happy to pay the storage overhead of extended attributes for mapping those ACLs. Anything else what speaks again using the xattr_darwinacls' branch approach?
___
Re the manually compiled kext: Yep, will keep it in /System/Library/Extensions then - though it feels like a strange place for user-compiled code ;)
The more I would appreciate support for this branch in an official release of O3X.
Last edited by roemer on Fri Apr 11, 2014 5:39 am, edited 1 time in total.
roemer
 
Posts: 73
Joined: Sat Mar 15, 2014 2:32 pm

Re: extended attributes and ACLs not handled correctly?

Postby ilovezfs » Fri Apr 11, 2014 12:00 am

I understand your desire. Nonetheless, this branch will almost certainly not receive any support going forward and may be deleted.
ilovezfs
 
Posts: 232
Joined: Thu Mar 06, 2014 7:58 am

Re: extended attributes and ACLs not handled correctly?

Postby roemer » Fri Apr 11, 2014 5:38 am

Actually a pitty - I just ran the 'backup bouncer' test again between HFS+ and a zfs pool under a (now correctly rebased) 'xattr_darwinacls' branch. I used rsync (-aNHAXx --fileflag), and the result looks quite promising now:

Code: Select all
Verifying:    basic-permissions ... ok (Critical)
Verifying:           timestamps ... ok (Critical)
Verifying:             symlinks ... ok (Critical)
Verifying:    symlink-ownership ... ok
Verifying:            hardlinks ... ok (Important)
Verifying:       resource-forks ... ok (Critical)
Verifying:         finder-flags ... ok (Critical)
Verifying:         finder-locks ... ok
Verifying:        creation-date ... FAIL                           (creation date is always set to system timestamp?)
Verifying:            bsd-flags ... ok
Verifying:       extended-attrs ... ok (Important)
Verifying: access-control-lists ... ok (Important)
Verifying:                 fifo ... ok
Verifying:              devices ... ok
Verifying:          combo-tests ... ok


The additional FinderFlags, which I reported in my initial post, are not there when using rsync. Seems to be something specific to the way ChronoSync makes its copies. Extended attributes, resource forks, flags, permissions, acls all seem fine, and stay fine once I do a round-trip with rsync back to HFS+ again.

But why is the creation date not maintained? Is this a side-effect of 'atime=off' or do I miss something else?
roemer
 
Posts: 73
Joined: Sat Mar 15, 2014 2:32 pm

Re: extended attributes and ACLs not handled correctly?

Postby ilovezfs » Fri Apr 11, 2014 4:12 pm

The "Date Created" thing may be a bug, and is unrelated to the atime property. Although the "Date Added" is stored in Spotlight, "Date Created" is not, so if we are in fact always returning system time or something for "Date Created" that is wrong.

I will reiterate again that we need to move on from this ACLs obsession.

Actual project priorities you should be obsessing about (to fill the void): https://openzfsonosx.org/wiki/Project_roadmap

And as you can see, it does not even mention the GUI.
ilovezfs
 
Posts: 232
Joined: Thu Mar 06, 2014 7:58 am

Re: extended attributes and ACLs not handled correctly?

Postby lundman » Sun Apr 13, 2014 6:21 pm

It is entirely possible we do not do the creation dates correctly, I have not looked too deeply into those glue functions. OSX also has more date related fields than ZFS (upstream) store, so in some places, the dates have been approximated.
User avatar
lundman
 
Posts: 1337
Joined: Thu Mar 06, 2014 2:05 pm
Location: Tokyo, Japan

Re: extended attributes and ACLs not handled correctly?

Postby ilovezfs » Mon Apr 14, 2014 10:49 pm

ilovezfs
 
Posts: 232
Joined: Thu Mar 06, 2014 7:58 am

Re: extended attributes and ACLs not handled correctly?

Postby roemer » Sun May 18, 2014 7:05 pm

ilovezfs wrote:Created an issue for this:
https://github.com/openzfsonosx/zfs/issues/147


Many thanks!
The latest release (v1.2.7) seems indeed to correctly copy the creation-dates.


For the moment, I will keep using the (re-based) 'xattr_darwinacls' branch though as these default ACLs are still there...
roemer
 
Posts: 73
Joined: Sat Mar 15, 2014 2:32 pm

Previous

Return to OpenZFS on OS X Development

Who is online

Users browsing this forum: No registered users and 23 guests