Re: [nfsv4] Chapter 12 for next rfc3530bis

"J. Bruce Fields" <bfields@fieldses.org> Tue, 12 October 2010 19:04 UTC

Return-Path: <bfields@fieldses.org>
X-Original-To: nfsv4@core3.amsl.com
Delivered-To: nfsv4@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E9393A6A44 for <nfsv4@core3.amsl.com>; Tue, 12 Oct 2010 12:04:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.579
X-Spam-Level:
X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXBd+hx9sWZU for <nfsv4@core3.amsl.com>; Tue, 12 Oct 2010 12:04:43 -0700 (PDT)
Received: from fieldses.org (fieldses.org [174.143.236.118]) by core3.amsl.com (Postfix) with ESMTP id BD2193A6A43 for <nfsv4@ietf.org>; Tue, 12 Oct 2010 12:04:42 -0700 (PDT)
Received: from bfields by fieldses.org with local (Exim 4.71) (envelope-from <bfields@fieldses.org>) id 1P5kAa-0007H0-LT; Tue, 12 Oct 2010 15:05:52 -0400
Date: Tue, 12 Oct 2010 15:05:52 -0400
From: "J. Bruce Fields" <bfields@fieldses.org>
To: david.noveck@emc.com
Message-ID: <20101012190552.GB25673@fieldses.org>
References: <BF3BB6D12298F54B89C8DCC1E4073D80027DD8CC@CORPUSMX50A.corp.emc.com> <20101012170759.GA22495@fieldses.org> <20101012170936.GB22495@fieldses.org> <BF3BB6D12298F54B89C8DCC1E4073D80027DDA78@CORPUSMX50A.corp.emc.com> <20101012182853.GA25673@fieldses.org> <BF3BB6D12298F54B89C8DCC1E4073D80027DDA91@CORPUSMX50A.corp.emc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <BF3BB6D12298F54B89C8DCC1E4073D80027DDA91@CORPUSMX50A.corp.emc.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: nfsv4@ietf.org
Subject: Re: [nfsv4] Chapter 12 for next rfc3530bis
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 12 Oct 2010 19:04:44 -0000

On Tue, Oct 12, 2010 at 02:47:40PM -0400, david.noveck@emc.com wrote:
> You as the server can enforce it by simply checking whether it is UTF-8
> and returning INVAL if it isn't.

Alas, no, if I get a getattr for the owner of a file, find the file is
owned by uid 8569, look up 8569 and it's somebody non-ascii and
non-utf8, my choices are:

	- Return an error, or claim not to support the owner attribute
	  on this file.
	- Attempt to guess the encoding and map to utf-8 before
	  returning.
	- Just return the username as it is.

And if I pick 3 (and it's what the code would do now, and seems the
least of evils), and the client tries to send the same name back to me
in a setattr, I can't see returning INVAL.

I could try to avoid getting into the whole situation in the first place
by forbidding those names.  That's not really up to me.

In the end I guess this just means I'll be violating the spec in some
(probably very unlikely?) cases.  Solaris too I bet, if it has
historically allowed such usernames.  It won't keep me up at night.

--b.

> The client is going to have some understanding of what it is being
> presented with and certainly can map an o-umlaut for example, to the
> UTF-8 version of that which is two bytes.  It is supposed to send UTF-8.
> 
> 
> -----Original Message-----
> From: J. Bruce Fields [mailto:bfields@fieldses.org] 
> Sent: Tuesday, October 12, 2010 2:29 PM
> To: Noveck, David
> Cc: Black, David; jlentini@netapp.com; nfsv4@ietf.org
> Subject: Re: [nfsv4] Chapter 12 for next rfc3530bis
> 
> On Tue, Oct 12, 2010 at 02:12:55PM -0400, david.noveck@emc.com wrote:
> > On Tue, Oct 12, 2010 at 01:07:59PM -0400, bfields wrote:
> > > I just want to make sure I'm getting into the business of mapping
> > 
> > (I meant to have a "not" there!)
> > 
> > > non-ascii non-utf8 usernames....
> > 
> > UVMUST says it MUST be UTF-8.  So if you get into the business of
> > mapping non-ascii non-utf8, you are non-compliant and you have only
> > yourself to blame for having to map stuff that you aren't supposed to
> > have accepted in the first place. 
> 
> I have some control over nfsd, but none over useradd.  If there are
> people out there with /etc/passwd's containing non-utf8 non-ascii
> usernames then the only way I'd see to enforce a MUST of utf-8 would be
> by taking a stab at what encoding they're using and then mapping to and
> from utf-8.  No thanks!
> 
> Hm, but non-ascii usernames can't be used in email addresses, can they?
> So maybe we'll never see them in practice.
> 
> --b.
>