On Wed, Sep 02, 2009 at 01:56:23PM -0500, Steve French wrote: > "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote on 09/02/2009 11:42:43 AM: > > On Wed, Sep 02, 2009 at 05:54:20PM +0530, Aneesh Kumar K.V wrote: > > > This patch series implement POSIX ACL support for NFSV4 clients > > > using sideband protocol. > > > > What motivates this? Who exactly wants this and why? What would be > > the advantages compared to other options, such as: > > The most obvious reason to me is that security information > can be lost as the ACL which was generated by Linux utilities and > client acl tools (which get/set posix acls) are converted by the Linux nfs > v4 client The kernel v4 client doesn't do that--it passes untouched v4 acls to and from userspace. (We do have some patches which do that conversion in libacl, but I don't believe any distribution has ever applied them.) > to NFSv4 ACLs on the wire and then the server converts them back to posix > to save them in ext3 (or ext4 or xfs etc.). This double conversion can > result > in a different ACL returned on subsequent queries (e.g. getfacl) than the > one that the user just set. Do you have an example? I may be forgetting some corner case, but I don't believe there should be any, *except* for those due to name<->id conversion. Which is a much larger problem. (There may also, of course, be translation problems even when only one side is translating--but I think the id/name translation is still the bigger problem.) > At worst this is a security exposure and at > best it is confusing to the user (and we don't control the tools). > And Linux client to Linux server is worse than Linux client to some other > servers because of the extra conversion (which is counter intuitive) > > > - native v4 support in filesystems, or > Doesn't help now. In the future would be nice to have something > similar to native cifs/ntfs/nfsv4 ACLs in btrfs - but that wouldn't help > for years - and won't help all of the other Linux > file systems. Here's one attempt for ext3: http://www.suse.de/~agruen/nfs4acl/ > CIFS and NTFS (and SMB2 in the future) could be modified to return > something like an NFSv4 ACL, but local file systems aren't likely to > change. Could be. I'd expect serious resistance, but nobody has really tried yet that I'm aware of. > In the meantime we don't even have > a generalized system interface to set/get nfsv4/cifs/ntfs acls so The current client is using raw xdr-formatted v4 acls in an extended attribute. We could consider some other interface if that would be more useful to other projects. (Andreas' patches have a different xattr-based interface which might serve as another example.) > Linux ACL tools and libraries and server software > like Samba could be updated to handle something other than > posix ACLs. I expect that jra and others of us on the Samba team > would love to see a few Linux file systems support CIFS/NFSv4/NTFS > ACLs but as he has reminded people - posix acls are Linux's native > ACL model. > > > - improved client-side acl tools that provided a user interface > > for v4 acls closer to that for v3 acls, or > Problem is that ACLs are a "system feature" and the OS tools, > utilities and desktop GUI tools for Linux use POSIX ACLs since > Linux's "native acl interface" is the posix one. It would make > sense to add a way to query the "preferred acl interface" > for a file system (and NFSv4 client could query the server > perhaps via a named attribute to determine the ACL type > preferred by the server fs). It is important to use the > native ACL model of the server operating system > so that information is not lost unnecessarily in the conversion. > > > - a v4.x extension to add support to the main protocol? > > Sounds fine to me to add an extension to the main protocol > but I doubt that it would be necessary - no extension was > formally added when v3 was extended for posix acls. > By analogy with cifs - we defined a new request and a new capability > bit for posix acl support. CIFS ACL support is expected > ("should" implement) but posix acl support is optional. The > Linux client uses posix acls if the server claims support for it > and it has not been disabled on the client by mount option. I'm sympathetic to this kind of argument, but it should be made at nfsv4@xxxxxxxxx It will be much harder to push patches that aren't based on something well on its way to standardization. --b. -- 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
