public inbox for linux-nfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: James Morris <jmorris@namei.org>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	linux-nfs@vger.kernel.org, Christoph Hellwig <hch@infradead.org>,
	linux-fsdevel@vger.kernel.org,
	Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: [PATCH 0/4][RFC] NFSv3: implement extended attribute (XATTR) protocol
Date: Sat, 19 Sep 2009 10:30:32 -0700	[thread overview]
Message-ID: <4AB51538.7060201@schaufler-ca.com> (raw)
In-Reply-To: <alpine.LRH.2.00.0909200020360.31818-CK9fWmtY32x9JUWOpEiw7w@public.gmane.org>

James Morris wrote:
> This patchset is the initial posting of an implementation of extended 
> attribute support for the Linux NFSv3 code, and intended as an RFC.
>
> This code is based initially on the GPL'd NFSv3 xattr code from IRIX 
> (thanks, Casey!),

You are welcome.

> as well as the existing Linux NFSv3 ACL code. It is 
> implemented as a side-protocol and should not affect any existing protocol 
> operation.  These patches are against the devel branch of the linux-nfs 
> tree.
>
> Currently, the code is implemented only to support Linux namespace.name 
> xattrs in the "user" namespace.

Why the limitation? It's been a while since I looked at that code,
but it seems that it would require extra effort to impose that
restriction. It has also proven that while Irix xattrs (which are
the basis for Linux xattrs) were intended for end user purposes
initially, they were only ever actually used for system attributes,
and almost exclusively security attributes at that.


> It could be extended to support other 
> similar name/value pair xattr implementations (and not far from IRIX wire 
> compat), although that's not an aim of this version.  There may also be 
> some scope for limited support of system xattrs (e.g. 'dumb' security 
> label transport), although I've not looked beyond user.* so far.
>   

I suggest that support for "dumb" security attributes will dramatically
increase the value and frequency of use of this facility. If you can
set/get SELinux security contexts and Smack labels you win. That will
be true (based on the Irix experience) even if the clients are SELinux
and the server not. I am familiar with the debates involving client-side
checks, server-side checks, policy mingling, and I do not need to be
reminded of them (by anyone (smiley here)). In real world deployments
there are meaningful situations for each permutation.

> Three operations are implemented by the new XATTR protocol and map to 
> syscalls:
>
>  - GETXATTR     getxattr(2)
>  - LISTXTTR     listxattr(2)
>  - SETXATTR     setxattr(2) and removexattr(2)
>
> This code passes basic testing of the above syscalls, although there are 
> some areas which still need work:
>
>  - Dynamic allocation of RPC buffers/pages (currently, the max size of 
>    e.g. the getxattr(2) value buffer is allocated at the RPC layer for 
>    each call -- suggestions on the best approach for this welcome)
>
>  - Determine appropriate NFS error codes for each operation
>
>  - Formal documentation of the XATTR protocol
>
>  - Interoperability with other OSs (we probably should at least
>    discuss with BSD folk)
>
>  - Handle size probing for getxattr(2) and listxattr(2) in the client 
>    (currently faked).  I think we should handle this at the client and not 
>    support it over the wire, as probes are almost always followed 
>    immediately by full calls, and the protocol can be kept simpler by 
>    expecting the client to perform a full call over the wire in response 
>    to a userland probe and caching the result.
>
>  - Caching of xattrs at the client
>
> Please review and comment!
>   

I endorse this approach, and have advocated it in the past. I am
delighted that someone has picked up the ball. This scheme works
very well in the real world.

> Note that I'll be giving a talk on this at LinuxCon on Thursday: 
> http://linuxcon.linuxfoundation.org/meetings/1589 So, in addition to 
> discussion here, please come along to the talk if you're at the conf, and 
> we may also be able to discuss it at Plumbers in one of the BoFs.
>
> Full diffstat:
>
>  fs/nfs/Kconfig             |   36 ++++
>  fs/nfs/Makefile            |    2 
>  fs/nfs/client.c            |   51 ++++++
>  fs/nfs/dir.c               |    8 -
>  fs/nfs/file.c              |    8 -
>  fs/nfs/internal.h          |   19 ++
>  fs/nfs/nfs3acl.c           |  155 +++++++++++--------
>  fs/nfs/nfs3xattr.c         |  264 +++++++++++++++++++++++++++++++++
>  fs/nfs/nfs3xattr_user.c    |   52 ++++++
>  fs/nfs/nfs3xdr.c           |  187 +++++++++++++++++++++++
>  fs/nfs/super.c             |    3 
>  fs/nfsd/Kconfig            |    8 +
>  fs/nfsd/Makefile           |    1 
>  fs/nfsd/nfs3xattr.c        |  352 +++++++++++++++++++++++++++++++++++++++++++++
>  fs/nfsd/nfsctl.c           |    3 
>  fs/nfsd/nfssvc.c           |   60 +++++++
>  fs/nfsd/vfs.c              |    5 
>  include/linux/nfs_fs.h     |   16 --
>  include/linux/nfs_fs_sb.h  |    3 
>  include/linux/nfs_mount.h  |    3 
>  include/linux/nfs_xattr.h  |   21 ++
>  include/linux/nfs_xdr.h    |   45 +++++
>  include/linux/nfsd/nfsd.h  |   13 +
>  include/linux/nfsd/xdr3.h  |   46 +++++
>  include/linux/sunrpc/svc.h |    2 
>  25 files changed, 1265 insertions(+), 98 deletions(-)
>
>
> - James
>   


  parent reply	other threads:[~2009-09-19 17:37 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-19 15:09 [PATCH 0/4][RFC] NFSv3: implement extended attribute (XATTR) protocol James Morris
2009-09-19 15:11 ` [PATCH 1/4] NFSv3: convert client to generic xattr API James Morris
2009-09-19 15:12 ` [PATCH 2/4] NFSv3: add xattr API config option for client James Morris
2009-09-19 15:13 ` [PATCH 3/4] NFSv3: add client implementation of XATTR protocol James Morris
2009-09-19 15:14 ` [PATCH 4/4] NFSv3: add server " James Morris
     [not found] ` <alpine.LRH.2.00.0909200020360.31818-CK9fWmtY32x9JUWOpEiw7w@public.gmane.org>
2009-09-19 17:30   ` Casey Schaufler [this message]
2009-09-20  5:13     ` [PATCH 0/4][RFC] NFSv3: implement extended attribute (XATTR) protocol James Morris
2009-09-22 12:47       ` Christoph Hellwig
2009-09-22 13:03         ` James Morris
     [not found]           ` <alpine.LRH.2.00.0909222253470.21052-CK9fWmtY32x9JUWOpEiw7w@public.gmane.org>
2009-09-22 13:07             ` Christoph Hellwig
2009-10-06 15:18   ` Peter Staubach
2009-10-09  0:39     ` James Morris
     [not found]       ` <alpine.LRH.2.00.0910091132130.32154-CK9fWmtY32x9JUWOpEiw7w@public.gmane.org>
2009-10-09 23:14         ` Christoph Hellwig
2009-10-12 17:50         ` Peter Staubach
2009-10-12 19:26           ` Tom Haynes
     [not found]             ` <CA06CB5C-6084-45AA-B185-FBDA7E3B9754-8AdZ+HgO7noAvxtiuMwx3w@public.gmane.org>
2009-10-12 19:34               ` Peter Staubach
2009-10-12 22:55                 ` Trond Myklebust
     [not found]                   ` <1255388158.3711.57.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-10-12 23:08                     ` J. Bruce Fields
2009-10-13  7:02                   ` James Morris
     [not found]                     ` <alpine.LRH.2.00.0910131733070.28896-CK9fWmtY32x9JUWOpEiw7w@public.gmane.org>
2009-10-13 18:27                       ` Trond Myklebust
     [not found]                         ` <1255458444.3711.113.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-10-14  0:48                           ` James Morris
     [not found]                             ` <alpine.LRH.2.00.0910141134410.4671-CK9fWmtY32x9JUWOpEiw7w@public.gmane.org>
2009-10-14  2:05                               ` Casey Schaufler
2009-10-14  4:30                                 ` James Morris
     [not found]                                   ` <alpine.LRH.2.00.0910141526530.5279-CK9fWmtY32x9JUWOpEiw7w@public.gmane.org>
2009-10-14  4:50                                     ` Casey Schaufler
2009-10-14 12:46                                       ` Peter Staubach
2009-10-14  4:56                               ` Dustin Kirkland
2009-10-14  6:02                                 ` James Morris
2009-10-14 15:05                             ` Tyler Hicks
     [not found] ` <bf63d7240910080919nf1bf6d0rd94f671d0645f674@mail.gmail.com>
2009-10-08 17:21   ` J. Bruce Fields
2009-10-09  0:31     ` James Morris
2009-10-08 17:22   ` J. Bruce Fields

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4AB51538.7060201@schaufler-ca.com \
    --to=casey@schaufler-ca.com \
    --cc=bfields@fieldses.org \
    --cc=hch@infradead.org \
    --cc=jmorris@namei.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trond.myklebust@fys.uio.no \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox