Return-Path: Date: Wed, 2 Sep 2009 13:56:23 -0500 Message-ID: <524f69650909021156lf181c17uf800eba7c35a6f45@mail.gmail.com> Subject: Re: POSIX ACL support for NFSV4 (using sideband protocol) From: Steve French To: "Aneesh Kumar K.V" , "J. Bruce Fields" Cc: linux-nfs@vger.kernel.org, nfsv4@linux-nfs.org, Trond Myklebust , ffilzlnx@linux.vnet.ibm.com, jra@samba.org, agruen@suse.de List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0331471346==" Sender: nfsv4-bounces@linux-nfs.org Errors-To: nfsv4-bounces@linux-nfs.org MIME-Version: 1.0 List-ID: --===============0331471346== Content-Type: multipart/alternative; boundary=000e0cd6d580c7e80a04729cd223 --000e0cd6d580c7e80a04729cd223 Content-Type: text/plain; charset=ISO-8859-1 "J. Bruce Fields" 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 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. 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. 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. In the meantime we don't even have a generalized system interface to set/get nfsv4/cifs/ntfs acls so 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. > > The ACL support can be disabled/enabled > > using -o noacl/-o acl mount option. The feature enables to > > view and modify POSIX acls from NFSv4 client. -- Thanks, Steve --000e0cd6d580c7e80a04729cd223 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable "J. Bruce Fields" <= bfields@fieldses.org> wrote on 09/02/2009 11:42:43 AM:
> On We= d, Sep 02, 2009 at 05:54:20PM +0530, Aneesh Kumar K.V wrote:
> &g= t; This patch series implement POSIX ACL support for NFSV4 clients
> > using sideband protocol.
>
> What motivates this?&nb= sp; Who exactly wants this and why?   What would be
> the a= dvantages compared to other options, such as:

The most obvious reaso= n 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 cli= ent
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 ca= n result
in a different ACL returned on subsequent queries (e.g. getfacl= ) than the
one that the user just set.  At worst this is a securit= y exposure and at
best it is confusing to the user (and we don't control the tools).
And L= inux client to Linux server is worse than Linux client to some other
se= rvers 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 y= ears - and won't help all of the other Linux
file systems.   CIFS and NTFS (and SMB2 in the future) could be <= br>modified to return something like an NFSv4 ACL, but local file systemsaren't likely to change.  In the meantime we don't even have
a ge= neralized system interface to set/get nfsv4/cifs/ntfs acls so
Linux ACL tools and libraries and server software
like Samba could be up= dated to handle something other than
posix ACLs.   I expect th= at 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 m= odel.

>    - improved client-side acl tools that p= rovided 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 &= quot;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 nam= ed 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 n= ot lost unnecessarily in the conversion.

>    - a = v4.x extension to add support to the main protocol?

Sounds fine to m= e 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. &nbs= p; 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.

> > T= he ACL support can be disabled/enabled
> > using -o noacl/-o acl mount option. The feature enables to
>= ; > view and  modify POSIX acls from NFSv4 client.

--
Thanks,

Steve
--000e0cd6d580c7e80a04729cd223-- --===============0331471346== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ NFSv4 mailing list NFSv4@linux-nfs.org http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4 --===============0331471346==--