From: Olga Kornievskaia <aglo@umich.edu>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
Simo Sorce <simo@redhat.com>
Subject: Re: [PATCH RFC 0/4] Use correct NFSv4.0 callback credential
Date: Fri, 18 May 2018 16:11:23 -0400 [thread overview]
Message-ID: <CAN-5tyFs4nxAwVynpr=Q5d_t+N5s9sa=2+1mj4-pZ-m1Xe3ZRA@mail.gmail.com> (raw)
In-Reply-To: <DB8E23EF-80A4-48D0-B53C-AD2A4B0076E2@oracle.com>
On Fri, May 18, 2018 at 3:23 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
>
>
>> On May 18, 2018, at 2:53 PM, Olga Kornievskaia <aglo@umich.edu> wrote:
>>
>> Hi Chuck,
>>
>> I'm not convinced that "srchost=" is necessary. I believe that
>> everything that is needed is suppose to be encoded in the "target="
>> option.
>
> I don't believe target= has what we want. For NFSv4.0 callback:
>
> A. The callback source principal needs to be the same as the client's
> NFS server target principal.
Correct and by specifying "nfs" and "*" I think that signals to the
gssd to pick the NFS server principal (which is what the client would
used as the target for the client to server authentication).
> B. The callback target principal needs to be the same as the client's
> NFS server source principal.
>
> Today, for NFSv4.0 callbacks, the kernel passes to gssd:
>
> target= it uses B for this
>
> service= it always sets this to "nfs"
>
> And gssd "makes up" the hostname part of A using gethostname(3), which
> is bogus for multi-homed NFS servers.
I agree that's bogus. Instead we should grab the domain from the
"target=" string.
> So my patch series does the following for NFSv4.0 callbacks:
>
> 1. It acquires the actual target principal the client used to establish
> it's lease. This is A above.
>
> 2. Instead of always passing "nfs" as the service= value, it passes
> the non-hostname part of A. That should be "nfs" but it doesn't
> have to be.
Ok so yes it has historically have always been "nfs" (even thought
it's only RECOMMENDED by the spec) and I don't think this is the case
to add complexity to change a well established behavior?
> 3. Instead of letting gssd make up the hostname part of the source
> principal, it passes the hostname part of A.
I'm arguing that hostname part of A should have been a part of the "target="
>
> That should provide the correct source principal in the multi-home
> case, and it should be backwards-compatible with older gssd's.
>
>
> Now here's why it's not enough to use getsockname(3) on target=
> to predict the correct source hostname:
>
> If the client has established the lease when mounting from one
> particular hostname, and then mounts from another, it will have
> to continue managing the lease using the principal it has already
> established with the first hostname. NFSD knows what that is, and
> can tell gssd what it needs to be. gssd, using only getsockname(3),
> would probably pick something that is wrong.
>
>
>> I thought target just needed to correctly identify the domain for
>> which authentication is taking place.
>
> That's what srchost= does. We can call it something else if that
> helps.
>
>
>> Then I think more changes should
>> be in nfs-utils to make sure that we find credentials for that
>> particular domain instead of going by the gethostbyname() results.
>
> That's a patch to gssd that I didn't post. I will post that later if
> we all agree srchost= is OK.
>
> srchost= is optional. If it's not present in the upcall, gssd will
> continue to use the result of gethostname(3) to construct the source
> principal.
>
>
>> On Fri, May 18, 2018 at 11:39 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
>>> I've been experimenting with this series that modifies NFSD to
>>> discover and use the correct GSS service principal when constructing
>>> its NFSv4.0 callback channels. I'm interested in review of this
>>> approach. There are a couple of code comments marked with XXX that
>>> also need some attention.
>>>
>>> The rpc.gssd change mentioned in 1/4 is unremarkable and will be
>>> made available once there is consensus about the kernel changes
>>> in this series. No gssproxy changes are necessary.
>>>
>>> ---
>>>
>>> Chuck Lever (4):
>>> sunrpc: Enable the kernel to specify the hostname part of service principals
>>> sunrpc: Extract target name into svc_cred
>>> nfsd: Use correct credential for NFSv4.0 callback with GSS
>>> nfsd: Remove callback_cred
>>>
>>>
>>> fs/nfsd/nfs4callback.c | 29 ++++----------
>>> fs/nfsd/nfs4state.c | 17 +++-----
>>> fs/nfsd/state.h | 2 -
>>> include/linux/sunrpc/svcauth.h | 3 +
>>> net/sunrpc/auth_gss/auth_gss.c | 20 ++++++++--
>>> net/sunrpc/auth_gss/gss_rpc_upcall.c | 70 ++++++++++++++++++++++------------
>>> 6 files changed, 80 insertions(+), 61 deletions(-)
>>>
>>> --
>>> Chuck Lever
>>> --
>>> 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
>> --
>> 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
>
> --
> Chuck Lever
>
>
>
next prev parent reply other threads:[~2018-05-18 20:11 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-18 15:39 [PATCH RFC 0/4] Use correct NFSv4.0 callback credential Chuck Lever
2018-05-18 15:39 ` [PATCH RFC 1/4] sunrpc: Enable the kernel to specify the hostname part of service principals Chuck Lever
2018-05-18 15:39 ` [PATCH RFC 2/4] sunrpc: Extract target name into svc_cred Chuck Lever
2018-05-18 15:39 ` [PATCH RFC 3/4] nfsd: Use correct credential for NFSv4.0 callback with GSS Chuck Lever
2018-05-18 15:39 ` [PATCH RFC 4/4] nfsd: Remove callback_cred Chuck Lever
2018-05-18 16:03 ` [PATCH RFC 0/4] Use correct NFSv4.0 callback credential Simo Sorce
2018-05-18 16:53 ` Chuck Lever
2018-05-18 17:07 ` Simo Sorce
2018-05-29 18:21 ` Fwd: " Chuck Lever
2018-05-29 19:13 ` J. Bruce Fields
2018-05-29 19:14 ` Chuck Lever
2018-08-15 22:27 ` Chuck Lever
2018-08-16 13:19 ` J. Bruce Fields
2018-05-18 18:53 ` Olga Kornievskaia
2018-05-18 19:05 ` Simo Sorce
2018-05-18 20:02 ` Olga Kornievskaia
2018-05-18 19:23 ` Chuck Lever
2018-05-18 20:11 ` Olga Kornievskaia [this message]
2018-05-18 20:19 ` Olga Kornievskaia
2018-05-18 20:42 ` Simo Sorce
2018-05-18 20:39 ` Simo Sorce
2018-05-18 20:56 ` Chuck Lever
2018-05-18 21:02 ` Olga Kornievskaia
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='CAN-5tyFs4nxAwVynpr=Q5d_t+N5s9sa=2+1mj4-pZ-m1Xe3ZRA@mail.gmail.com' \
--to=aglo@umich.edu \
--cc=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=simo@redhat.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).