Re: ACL handling for NFSv4
Re: ACL handling for NFSv4
- Subject: Re: ACL handling for NFSv4
- From: Michael Smith <email@hidden>
- Date: Wed, 19 Nov 2008 07:48:08 -0800
On Nov 13, 2008, at 12:38 PM, Rick Macklem wrote:
I finally have an NFSv4 server that includes support for NFSv4 ACLs,
so I
was hoping to tweak my NFSv4 Leopard client (http://code.google.com/p/macnfsv4
) to make use of them. (Note this is an
experimental open source project using a Kext that already goes
beyond the
KPIs, so I realize that the internal interfaces may change at any
time...)
Looking at xnu-1228 sources, it seems that getting an ACL from a file
system is done via vnode_getattr(), but is set via vn_setxattr()
setting
KAUTH_FILESEC_XATTR. Is that correct?
No, the operations are symmetric. If vnode_setattr() returns without
having claimed to have supported the ACL set, the fallback path will
attempt to save the ACL using an extended attribute. Likewise if the
ACL is requested and vnode_getattr() returns without claiming to have
supported the request, the fallback will look for an EA.
Part of my problem is that I don't have extended attribute support in
the server, so I don't have a way to store/retrieve the guid_t owner
and group fields in kauth_filesec on the server, which leads me to...
Check with Terry, however it's probably safe to either ignore these or
ask the local system to translate the UID/GID you have into GUIDs.
What are the guid_t owner and group fields of a kauth_filesec and is
there a way a client can map those to/from uid/gid or do they have to
be stored/retrieved from the file system? (If I have to store/retrieve
them, I suspect I'm snookered.)
There's a local translation service. See the kauth_* functions.
= Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden