Paul B. Henson wrote: > 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. >
I can't guarantee they will remain in the future. Thats why they aren't documented. It may be that with appropriate iterators and other interfaces they will no longer be needed. >> 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. Yep, the evaluation sort of thing is on our list of things to look into. -Mark _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
