site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Nov 13, 2008, at 12:38 PM, Rick Macklem wrote: 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... 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 (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... 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. 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. This email sent to site_archiver@lists.apple.com