From: Dr Fields James Bruce <bfields@fieldses.org>
To: Simo Sorce <simo@redhat.com>
Cc: Jeff Layton <jlayton@redhat.com>,
Trond Myklebust <trond.myklebust@primarydata.com>,
NFS <linux-nfs@vger.kernel.org>,
Adamson William Andros <androsadamson@gmail.com>,
Lever Charles Edward <chuck.lever@oracle.com>
Subject: Re: v4.0 CB_COMPOUND authentication failures
Date: Tue, 8 Apr 2014 14:11:58 -0400 [thread overview]
Message-ID: <20140408181158.GE9457@fieldses.org> (raw)
In-Reply-To: <1396980494.14203.169.camel@willson.li.ssimo.org>
On Tue, Apr 08, 2014 at 02:08:14PM -0400, Simo Sorce wrote:
> On Tue, 2014-04-08 at 14:04 -0400, Jeff Layton wrote:
> > On Tue, 08 Apr 2014 14:01:15 -0400
> > Simo Sorce <simo@redhat.com> wrote:
> >
> > > On Tue, 2014-04-08 at 13:30 -0400, Jeff Layton wrote:
> > > > On Tue, 08 Apr 2014 13:27:01 -0400
> > > > Simo Sorce <simo@redhat.com> wrote:
> > > >
> > > > > On Tue, 2014-04-08 at 12:44 -0400, Jeff Layton wrote:
> > > > > >
> > > > > > I think that's what happens. We only fall back to using AUTH_SYS if
> > > > > > nfs_create_rpc_client returns -EINVAL. In the event that the security
> > > > > > negotiation fails, we should get back -EACCES and that should bubble
> > > > > > back up to userland.
> > > > > >
> > > > > > The real problem is that gssd (and also the krb5 libs themselves) will
> > > > > > try to canonicalize the name. The resulting host portion of the SPN
> > > > > > may bear no resemblance to the hostname in the device string. In fact,
> > > > > > if you mount using an IP address then you're pretty much SOL.
> > > > >
> > > > > If you mount by IP do you really care about krb5 ? Probably not, maybe
> > > > > that's a clue we should not even try ...
> > > > >
> > > >
> > > > It's certainly possible that someone passes in an IP address but then
> > > > says "-o sec=krb5". It has worked in the past, so it's hard to know
> > > > whether and how many people actually depend on it.
> > > >
> > > > > > I haven't tried it yet, but it looks reasonably trivial to fix gssd
> > > > > > not to bother with DNS at all and just rely on the hostname. That
> > > > > > won't stop the krb5 libs from doing their canonicalization though. I'm
> > > > > > not sure if there's some way to ask the krb5 libs to avoid doing that.
> > > > >
> > > > > [libdefaults]
> > > > > rdns = false
> > > > >
> > > > > And I think we change the default to false in Fedora/RHEL lately ...
> > > > >
> > > > > Simo.
> > > > >
> > > >
> > > > That's a step in the right direction, but I think that the rdns just
> > > > makes it skip the reverse lookup. AFAIK, the MIT libs will still do
> > > > getaddrinfo and scrape out the ai_canonname and use that in preference
> > > > to the hostname you pass in.
> > >
> > > That should happen only if you are using a CNAME, not for an A name.
> > >
> > > We can open bugs if this is not the case though.
> > >
> >
> > That's still a problem for us then. The current code tries to compare
> > the host portion of the device string to the SPN that we get in the
> > callback request. If they don't match, it fails.
> >
> > I think what we need to do is fix this the right way -- make rpc.gssd
> > pass down the acceptor name with the downcall.
>
> Why do you need the comparison at all, pardon my ignorance, I do not
> know very well what its purpose is.
The NFS client wants to verify that a callback came from the server, so
it needs to know who it originally authenticated to.
(Though honestly it's unlikely you can do much damage by spoofing
callbacks.)
--b.
next prev parent reply other threads:[~2014-04-08 18:11 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-08 12:21 v4.0 CB_COMPOUND authentication failures Jeff Layton
2014-04-08 12:35 ` J. Bruce Fields
2014-04-08 12:42 ` Trond Myklebust
2014-04-08 12:57 ` Dr Fields James Bruce
2014-04-08 13:49 ` Jeff Layton
2014-04-08 14:03 ` J. Bruce Fields
2014-04-08 14:22 ` Jeff Layton
2014-04-08 14:41 ` Jeff Layton
2014-04-08 14:47 ` J. Bruce Fields
2014-04-08 14:23 ` Trond Myklebust
2014-04-08 14:46 ` Dr Fields James Bruce
2014-04-08 15:04 ` Jeff Layton
2014-04-08 15:13 ` Dr Fields James Bruce
2014-04-08 17:25 ` Simo Sorce
2014-04-08 17:28 ` Jeff Layton
2014-04-08 16:22 ` Trond Myklebust
2014-04-08 16:40 ` Dr Fields James Bruce
2014-04-08 17:30 ` Trond Myklebust
2014-04-08 17:55 ` Jeff Layton
2014-04-08 18:03 ` Trond Myklebust
2014-04-08 18:24 ` Jeff Layton
2014-04-08 18:45 ` Trond Myklebust
2014-04-08 18:49 ` Jeff Layton
2014-04-08 18:03 ` Dr Fields James Bruce
2014-04-08 16:44 ` Jeff Layton
2014-04-08 17:27 ` Simo Sorce
2014-04-08 17:30 ` Jeff Layton
2014-04-08 17:39 ` Frank Filz
2014-04-08 17:59 ` Jeff Layton
2014-04-08 18:06 ` Simo Sorce
2014-04-08 22:44 ` Frank Filz
2014-04-08 22:52 ` Simo Sorce
2014-04-08 23:31 ` Frank Filz
2014-04-08 18:01 ` Simo Sorce
2014-04-08 18:04 ` Jeff Layton
2014-04-08 18:08 ` Simo Sorce
2014-04-08 18:11 ` Dr Fields James Bruce [this message]
2014-04-08 18:52 ` Simo Sorce
2014-04-08 19:01 ` Trond Myklebust
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=20140408181158.GE9457@fieldses.org \
--to=bfields@fieldses.org \
--cc=androsadamson@gmail.com \
--cc=chuck.lever@oracle.com \
--cc=jlayton@redhat.com \
--cc=linux-nfs@vger.kernel.org \
--cc=simo@redhat.com \
--cc=trond.myklebust@primarydata.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 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.