On Fri, 15 Aug 2008, Mark Shellenbaum wrote: > The layout of the acl_t will likely change in the not too distant future. [...] > of the ACL, but they aren't documented interfaces, such as acl_data() > which will return you the pointer to the array of ace_t's and acl_cnt() > that will return you the number of ACEs in the array. With those two > interfaces you can then easily iterate over the ACL.
Ah, thanks for the pointer. Reviewing the libsec code, I see there is also acl_type(), and acl_flags(), but I don't see anything for accessing the acl_entry_size. However, both aclent_t and ace_t are publicly documented so sizeof() should do the trick. Are the libsec undocumented interfaces likely to remain the same when the acl_t structure changes? They will still require adding the prototypes to my code so the compiler knows what to make of them, but less chance of breakage is good. > We are currently investigating adding more functionality to libsec to > provide many of the things you desire. We will have iterators, editing > capabilities and so on. Sweet. Might I request an acl evaluation function? Which basically, given a user and a requested permission, returns either true (user has permission), false (user doesn't have permission), or error condition. Similar to the POSIX access() call, but for ACLs. If I had that I wouldn't need to be mucking around with the ACL directly at all :), as that's basically what I'm implementing... Thanks much, I always appreciate your informative responses. -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | [EMAIL PROTECTED] California State Polytechnic University | Pomona CA 91768 _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
