> On May 18, 2018, at 4:11 PM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote: > > On Fri, May 18, 2018 at 3:23 PM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: >> >> >>> On May 18, 2018, at 2:53 PM, Olga Kornievskaia <aglo@xxxxxxxxx> 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=" For a callback credential upcall: target name= client's principal @ client's hostname source name= server's principal @ server's hostname I don't see how gssd on a multi-homed server could derive "server's hostname" correctly from "client's hostname" in every case. As I explained below, the kernel retains the correct "server's hostname" string in clp->cl_cred even if the client should connect from another hostname within the lease expiry period. Example: Given a client manet that has - an interface named manet.domain - an interface named manet.other.domain - one key in its keytab: host/manet.domain@REALM And given a server klimt that has - an interface named klimt.domain - an interface named klimt.other.domain - a key in its keytab: nfs/klimt.domain@REALM - a key in its keytab: nfs/klimt.other.domain@REAM Now suppose the client manet mounts klimt.other with NFSv4.0 and sec=krb5. The client establishes a GSS context using: source=host/manet.domain@REALM target=nfs/klimt.other.domain@REALM and we want the server to establish a GSS context for the callback channel that looks like: source=nfs/klimt.other.domain@REALM target=host/manet.domain@REALM How does gssd construct the correct source principal given the target host/manet.domain@REALM ? Today it picks nfs/klimt.domain@REALM , which is incorrect. Further, if the client then connects via klimt.domain but continues to use the original GSS context and lease, how does gssd know it needs to use source=nfs/klimt.other.domain@REALM if it needs to re-establish the callback context for some reason? The only way gssd can know these things for certain is if the kernel explicitly requests "nfs/klimt.other.domain@REALM" as the source principal for this GSS context. srchost= enables the kernel to request a specific hostname for the source principal. Currently our upcall does not specify a REALM for either principal, but that should be straightforward to add. I'm in favor of not having magic in gssd that figures this stuff out based on a heuristic, but rather I'd like the kernel ask for precisely what it needs every time. >> 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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx >>>> 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@xxxxxxxxxxxxxxx >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> -- >> Chuck Lever -- Chuck Lever -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
