On Thu, Sep 3, 2009 at 1:20 AM, Ondrej Valousek<webserv@xxxxxxxxxx> wrote: > >> 2) If POSIX->NFSv4 client mapping is done (as had been suggested IIRC >> by others in the past) at least you lose less data (NFSv4 ACLs are >> "richer" >> in function than POSIX ACLs - so at least with the POSIX->NFSv4->POSIX >> case you are limiting the user to the subset of choices which are actually >> going to be able to be stored, no inheritence etc.) >> > I must say that I do not understand the motivation either. POSIX is not even > a standard and should be replaced with NFSv4 acls. > Even now ext3/ext4 support NFSv4 acls (ok. patch is needed but the patch is > there already). If someone were able to convince the linux-fsdevel community to change fs/posix_acls.c (or add an fs/cifs_acls.c) to handle NFSv4/CIFS/NTFS ACL evaluation, and add support to store these richer ACLs on disk for the future (e.g. for btrfs), that would be great - but with no local file system in kernel which can store NFSv4 ACLs and no code to evaluate these ACLs in the VFS and with a NACK from fsdevel when others tried this a few years ago (even after MacOS and others moved to the CIFS/NTFS ACLs model) > If the decision was up to me, I would forbid any nfsv4 acls if the server > can not store them properly (i.e. without any conversion) That would be a pretty dramatic loss of function - being forced to use the primitive mode bits to protect files if the server were Linux - and could be worseeven NetApp does some ACL mapping -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
