site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com And the fallback for extended attributes will create ._ files. 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... -- Terry _______________________________________________ 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... On Nov 19, 2008, at 7:48 AM, Michael Smith wrote: 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. ACLs are dealt with in terms of filesec_t's, whise contents are intended to be considered opaque in user space, and for which there are no user space functions for setting certain parts of them. In practice, there is only check/read/modify/write, where if the check fails you do not do the read/modify/write, and if the check succeeds, you do the read/modify/write, and if you want to set one, you do a read/modify/write and the read cons's up the information that you can't create in user space, and you modify that to add the ACEs you want - the chmod and ls source code is a good reference. Best practice is to not use these fields, and to not set their validity flags when round-tripping in/out of filesec_t's (kauth_filesec's, in non-pointer references). NOTE TO CASUAL ARCHIVE READERS: UNLESS YOU ARE A FILESYSTEM IMPLEMENTOR RUNNING IN THE KERNEL, LEAVE THESE THE HECK ALONE!!! 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. As long as these are not set, then they won't be an issue. The filesec_t is the contract between user space (libc POSIX 1003.1e, generally) and the kernel. Unless you return the values, the read/ modify/write from before won't set them, and so there will be no need to fake them up. 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. Specifically, the kernel does not explicitly know about uuids/guids/ ntsids. The kernel know about integers, and it know how to ask that integers be translated to/from these things. All POSIX enforcement is based on integers, all credential information (other than MAC labels) is handled as integers, and you can't get at MAC labels and shouldn't try, due to scoping rules. 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. Another thing to avoid is the (incorrect) assumption that because NTSIDs are permitted to be variable length that the functions to deal with their translation also expect variable length; while you are permitted to ask about shorter ones, you have to provide for storage of the largest possible one. Unless you are SMBFS or XSan, this should not be an issue for you, but it is a potential place where you'd write off the end of your memory during a copy/create operation (C99 prohibits the use of a variant array at the end of a structure embedded in a structure; gcc allows this if the first structure is at the end of the second, rather than in the middle, but this is technically a non-standard usage). This email sent to site_archiver@lists.apple.com