On Thursday 10 October 2002 09:46 pm, [EMAIL PROTECTED] wrote: > The problem with implementing getsecattr and setsecattr calls for AFS > is that the permission bits that those calls assume are different from > the rlidwka permission bits in AFS. You could try to map the rlidwka > bits into thet unix-style rwx bits, but what's the point? You wouldn't > be able to usefully map them back, when the user tries to change them > with setfacl.
This is the general problem of different ACL implementations. Mapping from one ACL schema to another, also attmepting to take into account the UNIX mode bits is difficult / impossible to handle without some sort of information loss. For some real fun, check out the NFS4 working group mailing lists at http://www.nfs4.org/ for some 'lively' discussions on this subject. In a nutshell, NFSv4 will speak on-the-wire ACLs that very closely (or mabye nearly 100%) model NTFS ACLs. They've got the forward and reverse mapping between these and UNIX mode bits laid down, but the folks who want to 'do the right thing' for implementing a NFSv4 server on UNIXen which support POSIX filesystem ACLs may or may not be able to produce a functional mapping that will allow them to ultimately just defer to the fileserver's underlying filesystem's ACL model, which would be a real win for those fileservers that also happen to be NFSv3 servers. Add to that mix their other juicy issue of principal names being either X.500 names or K5 principal names and the desire to allow for a server to deal with both correctly, and you've got a complex system on your hands. That said, how many AFS sites out there are keeping an eye on NFSv4? K5 (er, well, GSS) support out of the box. ACLs. Heterogenous support. Multivendor support and opensource implementations. We love AFS, but have a love / hate relationship with the Win32 support, as I bet a lot of sites do. Somebody could make a good bit of cash selling support to universities by producing a commercial Win32 client. -- James Robinson Phone: (704) 687-4876 College of Information Technology FAX: (704) 687-3516 UNC Charlotte Email: [EMAIL PROTECTED] Charlotte, NC 28223-0001 Director of Technology Services _______________________________________________ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
