site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Thu, 20 Nov 2008, Terry Lambert wrote: Great, sounds like I don't have to worry about filesec_t's, just the ACLs. Hmm, I seem to be stuck using these. For a setattr, what I have to put on the wire is an ACL with "who" entries in the ACEs that look like: @OWNER, @GROUP, ... or name@dns.domain (where "name" is a user or group name) The only way I see I can do this are the kauth_cred_guid2* calls. Correct? But, if these fail for any reason, it's really not my problem. All I do is return the error on the VNOP_SETATTR() call. (ie. If they fail, it just limits what ACLs can be set on the server.) _______________________________________________ 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... [good stuff snipped] 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. [more good stuff snipped] So if I have an ACE I am trying to set, since the storage format *happens* to be GUID, then we translate the integer for the gid and uid of the current credential into a GUID for the purposes of storage. For the purposes of comparison on lookup, we then convert the current credential into a GUID (in general, the uid, since that is the primary identity in a credential), and compare the GUID to the GUID in the ACE. This is handled in xnu in bsd/kern/kern_authorization.c:kauth_acl_evaluate(). Although there are support functions for translating the other direction, e.g. kauth_cred_guid2uid(), and kauth_cred_guid2gid() no one uses them, and I would, in fact, like to keep things that way. The only exception to this is kauth_cred_guid2gid() is used by kauth_cred_ismember_guid() when attempting to set a group owner on a file. This use is poorly supported by the rest of the code and should be avoided. Now, it seems that I have to get the "who" from the ace_applicable field of the ace in the ACL passed down through VNOP_SETATTR(). For @OWNER, @GROUP,... the kauth_wellknown_guid() should handle it, but when it returns KAUTH_WKG_NOT, I have an ace_applicable field that I need to turn into a uid or gid. (Once I have a uid or gid, I already have a cache plus upcall to a userland daemon to turn that into "name@dns.domain".) Basically, I'd like to thank Mike and Terry for their great responses. I think I know what I need to do now, rick. This email sent to site_archiver@lists.apple.com