From: Simo Sorce <simo@redhat.com>
To: Jeff Layton <jlayton@redhat.com>
Cc: Trond Myklebust <trond.myklebust@primarydata.com>,
Dr Fields James Bruce <bfields@fieldses.org>,
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, 08 Apr 2014 14:08:14 -0400 [thread overview]
Message-ID: <1396980494.14203.169.camel@willson.li.ssimo.org> (raw)
In-Reply-To: <20140408140447.51695274@tlielax.poochiereds.net>
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.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
next prev parent reply other threads:[~2014-04-08 18:08 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 [this message]
2014-04-08 18:11 ` Dr Fields James Bruce
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=1396980494.14203.169.camel@willson.li.ssimo.org \
--to=simo@redhat.com \
--cc=androsadamson@gmail.com \
--cc=bfields@fieldses.org \
--cc=chuck.lever@oracle.com \
--cc=jlayton@redhat.com \
--cc=linux-nfs@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox