linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Jim Rees <rees@umich.edu>
Cc: Gregor Gruener <ggruner@redhat.com>, linux-nfs@vger.kernel.org
Subject: Re: [PATCH 2.6.32-131.6.1.el6.x86_64] idmapd.c: deactivate the ASCII characters check
Date: Tue, 28 Feb 2012 14:55:36 -0500	[thread overview]
Message-ID: <20120228195535.GC2723@fieldses.org> (raw)
In-Reply-To: <20120223130245.GA4776@umich.edu>

On Thu, Feb 23, 2012 at 08:02:45AM -0500, Jim Rees wrote:
> Gregor Gruener wrote:
> 
>   Customers are using Unicode characters umlauts (ö,ä,ü) in group names and this
>   creates problems with NFS ID Mapping. Groups with umlauts will be redirected to
>   the group NFS "nobody".
>   This patch deactivate the ASCII characters check. It's maybe more like a temporary fix and I think it would be nicer to
>   adjust the check to support Unicode characters instead to deactivate the
>   check.
> 
> Maybe the name of the routine should also be changed to something other than
> validateascii().  But I'm curious why that check was put in there.

Sounds totally wrong.

By the nfs rfc's of course, if we're going to check anything we should
be checking for utf8.

Though even then, it's hard to see how failing and mapping to nobody
really helps anyone here once they already have a non-utf8 name.

Best might be to allow a non-utf8 mapping and print a one-time warning.
And work on fixing any account-creation tools to enforce utf8.

> 
> I found this in rfc5661 section 22.1, which seems to be a bug in the spec:
> 
>    1.  A US-ASCII string name that is the actual name of the attribute.
>        This name must be unique.  This string name can be 1 to 128 UTF-8
>        characters long.

Oops.

--b.

  reply	other threads:[~2012-02-28 19:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-23  9:16 [PATCH 2.6.32-131.6.1.el6.x86_64] idmapd.c: deactivate the ASCII characters check Gregor Gruener
2012-02-23 13:02 ` Jim Rees
2012-02-28 19:55   ` J. Bruce Fields [this message]
2012-02-29 20:48 ` Steve Dickson
2012-02-29 21:38   ` Jim Rees
2012-03-01 15:22     ` Steve Dickson
2012-05-17 17:40   ` Sorin Faibish
2012-05-17 17:43   ` pNFS block performance evaluation (sorry for the wrong subject title) Sorin Faibish
2012-05-18  9:37     ` tao.peng

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=20120228195535.GC2723@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=ggruner@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=rees@umich.edu \
    /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;
as well as URLs for NNTP newsgroup(s).