All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Steve Dickson <SteveD@redhat.com>, Spelic <spelic@shiftmail.org>,
	linux-nfs@vger.kernel.org
Subject: Re: NFSv4 behaviour on unknown users
Date: Tue, 30 Nov 2010 17:36:27 -0500	[thread overview]
Message-ID: <20101130223627.GC5054@fieldses.org> (raw)
In-Reply-To: <1291156414.4393.2.camel@heimdal.trondhjem.org>

On Tue, Nov 30, 2010 at 05:33:34PM -0500, Trond Myklebust wrote:
> On Tue, 2010-11-30 at 17:26 -0500, J. Bruce Fields wrote:
> > On Tue, Nov 30, 2010 at 05:19:38PM -0500, Trond Myklebust wrote:
> > > On Tue, 2010-11-30 at 10:36 -0500, Steve Dickson wrote:
> > > > 
> > > > On 11/29/2010 02:09 PM, Trond Myklebust wrote:
> > > > > On Mon, 2010-11-29 at 14:01 -0500, J. Bruce Fields wrote:
> > > > >> On Mon, Nov 29, 2010 at 07:38:30PM +0100, Spelic wrote:
> > > > >>> On 11/29/2010 07:22 PM, Trond Myklebust wrote:
> > > > >>>> On Mon, 2010-11-29 at 19:12 +0100, Spelic wrote:
> > > > >>>> No. That is not allowed by the spec.
> > > > >>>>
> > > > >>>> Trond
> > > > >>>
> > > > >>> Too bad!! :-((
> > > > >>> Was that spec decision really wise? :-/
> > > > >>>
> > > > >>>
> > > > >>> BTW:
> > > > >>> I've just noticed two discussions dated a few months ago in this ML
> > > > >>> regarding this.
> > > > >>> the thread named 'numeric UIDs'
> > > > >>
> > > > >> There's also a reference to the spec language there--we'd be violating a
> > > > >> "SHOULD", but I think it would be acceptable if it smooths the v3->v4
> > > > >> upgrade path for users in your situation.
> > > > >>
> > > > >> I think steved's changes still need to be ported to libnfsidmap?
> > > > > 
> > > > > I don't see how steved's changes will fix this problem. If the client
> > > > > has a mapping, it will (MUST) send the mapped uid/gid and the server
> > > > > still has to make sense of that. Ditto if the server has a mapping, and
> > > > > the client does not.
> > > > I actually thought it did... 
> > > 
> > > How? The userland library has no concept of whether or not the server
> > > accepts unmapped uids and gids.
> > > 
> > > > Now that the libnfsidmap maintainership has been handed over to me 
> > > > and I'm about to enable the new nfsidmapper when I commit the 
> > > > "libnfsidmap: Add numerical string translation" patch... Its 
> > > > probably time I take a second look at those patches to see
> > > > if we can ease some of this pain...
> > > 
> > > Some reasons for doing this in the kernel are:
> > > 
> > > 1) it is easy to do so.
> > > 2) it allows the kernel to take action to recover
> > > 3) it fixes the nfsroot problem, provided that the server also sends
> > > uids/gids in this situation.
> > 
> > Makes sense to me.
> > 
> > The server side might still be easiest to do in idmapd/libnfsidmap.
> 
> The NFS server has to be able to tell the idmapper which variety of
> mapping it wants. The reason is, as I said, that we want to handle
> RPCSEC_GSS based authentication (and possibly AUTH_NULL too) differently
> from AUTH_SYS. The idmapper by itself has no way to distinguish what
> authentication the client used.

I still don't understand what the advantage of that would be: why would
we want to return different file owners depending on which
authentication flavor the client's request used?

--b.

  reply	other threads:[~2010-11-30 22:36 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-29 18:12 NFSv4 behaviour on unknown users Spelic
2010-11-29 18:22 ` Trond Myklebust
2010-11-29 18:38   ` Spelic
2010-11-29 19:01     ` J. Bruce Fields
2010-11-29 19:09       ` Trond Myklebust
2010-11-30 15:36         ` Steve Dickson
2010-11-30 22:19           ` Trond Myklebust
2010-11-30 22:26             ` J. Bruce Fields
2010-11-30 22:33               ` Trond Myklebust
2010-11-30 22:36                 ` J. Bruce Fields [this message]
2010-11-30 22:47                   ` Trond Myklebust
2010-12-01  2:57                   ` Neil Brown
2010-12-01  3:10                     ` Trond Myklebust
2010-12-01  3:23                       ` Neil Brown
2010-12-01 16:29                       ` J. Bruce Fields
2010-12-02 23:10                         ` Thomas Haynes
2010-12-02 23:18                           ` Trond Myklebust
2010-12-02 23:28                             ` Spencer Shepler
2010-12-08  0:15                               ` 'J. Bruce Fields'
2010-12-10 19:00                                 ` Thomas Haynes
2010-12-10 19:17                                   ` J. Bruce Fields
2010-11-29 22:09   ` Daniel.Muntz
2010-11-29 22:57     ` Spencer Shepler
2010-11-29 23:16       ` Trond Myklebust
2010-11-29 23:25         ` Spencer Shepler
2010-11-29 23:26         ` Trond Myklebust
2010-11-29 23:30           ` Spencer Shepler
2010-11-29 23:40             ` Trond Myklebust
2010-11-30  0:02               ` Spencer Shepler
2010-11-30 11:44                 ` Spelic
2010-11-30 13:04                   ` Trond Myklebust
2010-11-30 15:48                     ` Boaz Harrosh
2010-11-29 23:34       ` Daniel.Muntz
2010-11-29 23:36         ` Spencer Shepler
  -- strict thread matches above, loose matches on Subject: below --
2010-11-29 17:32 Spelic
2010-11-29 19:50 ` Simon Kirby
2010-11-29 22:47   ` Spelic
2010-11-30 15:20     ` Chuck Lever

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=20101130223627.GC5054@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=SteveD@redhat.com \
    --cc=Trond.Myklebust@netapp.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=spelic@shiftmail.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.