Re: [nfsv4] Review of http://www.ietf.org/id/draft-naik-nfsv4-xattrs-01.txt
David Quigley <dpquigl@davequigley.com> Wed, 08 October 2014 14:19 UTC
Return-Path: <dpquigl@davequigley.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E85171A1A93 for <nfsv4@ietfa.amsl.com>; Wed, 8 Oct 2014 07:19:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Vc8rygmz_96 for <nfsv4@ietfa.amsl.com>; Wed, 8 Oct 2014 07:19:15 -0700 (PDT)
Received: from countercultured.net (countercultured.net [IPv6:2001:470:0:c0d3::2]) by ietfa.amsl.com (Postfix) with SMTP id 24D681A1B1D for <nfsv4@ietf.org>; Wed, 8 Oct 2014 07:19:15 -0700 (PDT)
Received: (qmail 17356 invoked from network); 8 Oct 2014 14:19:14 -0000
Received: from countercultured.net (HELO webmail.countercultured.net) (2001:470:0:c0d3::2) by countercultured.net with SMTP; 8 Oct 2014 14:19:14 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Wed, 08 Oct 2014 10:19:14 -0400
From: David Quigley <dpquigl@davequigley.com>
To: "Matt W. Benjamin" <matt@linuxbox.com>
In-Reply-To: <1559267819.50.1412777333004.JavaMail.root@thunderbeast.private.linuxbox.com>
References: <1559267819.50.1412777333004.JavaMail.root@thunderbeast.private.linuxbox.com>
Message-ID: <178fb1550b518bf99fc6c6575f47a5e2@countercultured.net>
X-Sender: dpquigl@davequigley.com
User-Agent: Roundcube Webmail/1.0.2
Archived-At: http://mailarchive.ietf.org/arch/msg/nfsv4/qOdEf7pvLM8Pr9Xq84uu-8ndJ_4
Cc: Nico Williams <nico@cryptonector.com>, NFSv4 <nfsv4@ietf.org>
Subject: Re: [nfsv4] Review of http://www.ietf.org/id/draft-naik-nfsv4-xattrs-01.txt
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Oct 2014 14:19:17 -0000
On 10/08/2014 10:08, Matt W. Benjamin wrote: > Hi, > > ----- "David Quigley" <dpquigl@davequigley.com> wrote: > <snip> > >> xattr for its internal access control but anything beyond that I don't >> >> think is ok. Trond in the past has expressed concerns about people >> establishing arbitrary sub protocols by using xattrs. I agree that >> this >> is a problem because it opens up the system to interoperability issues >> >> by encouraging people to bypass any sort of standardization effort and >> >> just using the excuse that its just opaque data. > > I find this argument a bit strange. A general-purpose tool like xattr > allows > application developers and users to evolve subprotocols to satisfy real > use > case scenarios. The need to interoperate arises naturally to > reduce/remove > impedence amongst competing approaches/implementations, so that what > is standardized > arises from existing practice and experience. > > Matt Application use of xattrs isn't the issue here. The issue is when you have system components (such as an OS level security model) making decisions based off of these xattrs. If you want something handled by NFS then define it properly in the protocol. Don't attempt to make protocol extensions by cramming data into xattrs to be used by the OS out of band from NFS. The fear with xattrs and something like Labeled NFS was that it could have been used to apply access control on NFSv4 while being completely out of band from the protocol. If we exposed security.* and SELinux or SMACK used those xattrs directly you now have access control on NFSv4 file objects that is completely out of band from the main protocol itself. Likewise what happens if you decide that you want to as a vendor add some additional information to pNFS and cram it into an xattr and just have a couple of implementations know about that information and use it? Those are the interoperability concerns I'm talking about (and if I understood trond what he was talking about as well). The point is xattrs shouldn't be used as a way to skirt around properly defining protocol extensions. Dave
- [nfsv4] Review of http://www.ietf.org/id/draft-na… Tom Haynes
- Re: [nfsv4] Review of http://www.ietf.org/id/draf… Tom Haynes
- Re: [nfsv4] Review of http://www.ietf.org/id/draf… J. Bruce Fields
- Re: [nfsv4] Review of http://www.ietf.org/id/draf… Manoj Naik
- Re: [nfsv4] Review of http://www.ietf.org/id/draf… Thomas Haynes
- Re: [nfsv4] Review of http://www.ietf.org/id/draf… Manoj Naik
- Re: [nfsv4] Review of http://www.ietf.org/id/draf… Nico Williams
- Re: [nfsv4] Review of http://www.ietf.org/id/draf… Thomas Haynes
- Re: [nfsv4] Review of http://www.ietf.org/id/draf… Nico Williams
- Re: [nfsv4] Review of http://www.ietf.org/id/draf… Christoph Hellwig
- Re: [nfsv4] Review of http://www.ietf.org/id/draf… Christoph Hellwig
- Re: [nfsv4] Review of http://www.ietf.org/id/draf… David Quigley
- Re: [nfsv4] Review of http://www.ietf.org/id/draf… Matt W. Benjamin
- Re: [nfsv4] Review of http://www.ietf.org/id/draf… David Quigley
- Re: [nfsv4] Review of http://www.ietf.org/id/draf… Nico Williams