From: Trond Myklebust <Trond.Myklebust@netapp.com>
To: Thomas Haynes <thomas@netapp.com>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
Spelic <spelic@shiftmail.org>,
linux-nfs@vger.kernel.org
Subject: Re: NFSv4 behaviour on unknown users
Date: Thu, 02 Dec 2010 18:18:05 -0500 [thread overview]
Message-ID: <1291331885.2915.1.camel@heimdal.trondhjem.org> (raw)
In-Reply-To: <99BBEF51-7EB1-4BAA-9B12-F0F98A629C74@netapp.com>
On Thu, 2010-12-02 at 17:10 -0600, Thomas Haynes wrote:
> On Dec 1, 2010, at 10:29 AM, J. Bruce Fields wrote:
>
> > On Tue, Nov 30, 2010 at 10:10:02PM -0500, Trond Myklebust wrote:
> >>
> >> I think you need to take beepy's words in context here: as I believe I
> >> mentioned previously, RFC3530 (and its predecessor RFC3010) assumed
> >> everyone would be using principals for authenticating, either through
> >> RPCSEC_GSS w/ krb5, or through the SPKM/Lipkey mechanism. So sure was
> >> everyone of this, that AUTH_SYS isn't even mentioned as a valid
> >> authentication mechanism, and so nobody had to worry about the
> >> consequences of using it.
> >
> > I also wonder whether the value of a transparent upgrade from NFSv3 got
> > a little lost.
> >
> > To me that seems like the first requirement for version n+1 of
> > anything--that we should be able to upgrade people to version n without
> > their noticing.
> >
> > Maybe there are features that are necessarily incompatible, and that
> > merit the downside, but the downside--losing the chance to get new
> > features to every user automatically--seems significant to me.
> >
> >
> > And, perhaps it's a disease, but I have gotten into the habit of
> > thinking of the (krb5 principal)->(id, gid's) mapping as independent of
> > the (NFSv4 user name)<->(uid) and (NFSv4 group name)<->(gid) mappings.
> >
> > Granted they have to be coordinated on any reasonably complicated setup.
> > But there are simple cases where they don't necessarily need to be.
> >
> > E.g. on a dumb "cp -ax / /nfs" backup it doesn't really matter "who"
> > does the backup as long as they have sufficient permissions, since the
> > files will all be explicitly chown'd as they're created. And with krb5
> > it's simple enough to make that work with a single static mapping from a
> > client-side principal to root on the server.
> >
> > And, again, that's something that works now with NFSv3.
> >
> > --b.
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
> Another question is whether or not such an approach would be appreciated
> as part of 3530bis?
You want to add a discussion about AUTH_SYS support for 3530bis? I'd be
OK with that...
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
next prev parent reply other threads:[~2010-12-02 23:18 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
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 [this message]
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=1291331885.2915.1.camel@heimdal.trondhjem.org \
--to=trond.myklebust@netapp.com \
--cc=bfields@fieldses.org \
--cc=linux-nfs@vger.kernel.org \
--cc=spelic@shiftmail.org \
--cc=thomas@netapp.com \
/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).