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