On Thu, Sep 03, 2009 at 08:54:06AM -0500, Steve French wrote: > 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 I don't remember that--do you have a pointer? --b. > 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 -- 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
