On Tue, Sep 9, 2014 at 7:18 PM, Nordgren, Bryce L -FS <bnordgren@xxxxxxxxx> wrote: > >> Per Oracle support this is not quite correct: if you have multiple tickets in a >> DIR: then the NFS client is either required to negotiate with the server (RFC >> 3530) or try the credentials in order until one works. > > "negotiate" appears to mean select a security mechanism, such as Kerberos vs. something else. Is there actually an "intra-mechanism" requirement? > >> Still it has to try all options, i.e. negotiate. This is what the reference >> implementation for NFS (Solaris) does. Is it time to party like it's 1999? Who listed Solaris as the functional reference for the Linux rpc.gssd daemon while I wasn't looking? rpc.gssd and its intended user functionality is listed in its manpage. Feel free to put in a feature request if you think that new functionality is needed to support a good use case that you may have, but please don't try to pass it off as a protocol requirement that we're not fulfilling unless you are prepared to point to chapter and verse of the relevant RFC. A quick grep will show you that there is nothing in RFC3530 that even mentions kerberos tickets, let alone describes how they are to be managed if you have more than one. Neither does RFC2623. > What are "all the options"? It could try nfs/fqdn@REALM for each REALM present in your ticket cache. It could maintain a separate list of realms not in your cache to be tried. It could let the user specify a principal to try. This has nothing to do with client/server communication and more with probing the Kerberos trust network to see if there is a path to walk from one of the credentials in your cache to one of the potential service principals. > > I think what you're saying is that after the negotiation has settled on Kerberos, you want more aggressive probing. > > Alternatively, in lieu of aggressive probing (which would yield shared Kerberos user principal trustable by both client and server), you want the id mapper on the NFS client and on the NFS server to map the same NFS id to different Kerberos principals. And then the client system should also know what Kerberos principal the server system has mapped to the relevant NFS ID (server-wide? For a particular mount point?). And both client-recognized and server-recognized Kerberos principals must be in the user's cache. And trust that the two principals are the same ultimately stems from the fact that they're in the same user's Kerberos cache, which is presumably under the control of one human. But I think there still has to be a trust path from NFS client to NFS server. Or no? > > Do NFS ID mappers talk to one another? How would they negotiate? I think I need a picture to nail down all the moving parts. RFC3530 does not describe any form of NFS id mapper negotiation. That lies entirely outside the scope of the protocol, and is usually ensured by deploying third party solutions such as LDAP. In the NFSv4 spec, the client just asserts a "owner@dns_domain" or "owner_group@dns_domain" string as part of a SETATTR command to set an ACL or a file owner/owner_group, and either the server recognises it or it doesn't. If the server doesn't recognise the string, then it returns an error, and the acl/ownership change is not allowed. On the other hand, the client accepts whatever owner@domain or owner_group@domain strings the server returns as part of a GETATTR or READDIR command to retrieve an ACL or file owner/owner_group. If the client doesn't have a mapping, then it will usually try to represent the string as an anonymous user/owner so that it can at least list something that the application can recognise. Either way, the client isn't allowed to use any of that idmapping information for file access or other security enforcement tasks. Such enforcement decisions are rather done through RPC calls directly to the server, and that may be authenticated by an RPCSEC_GSS session. E.g. if the client is trying to decide if it should allow a process access to the cached data for a given file, then it should send an ACCESS rpc call to the server. It will never try to read the ACL directly and interpret that. If the client wants to know if a process is allowed to create a directory, it sends an RPC call that attempts the operation. IOW: the NFSv4 protocol limits the scope of the problem by trying to be robust against relying on idmapping for security purposes, but limiting the functionality available to applications if your client and server don't have a way to share idmapping information (ability to set/read/modify acls, or to change file ownership). -- Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@xxxxxxxxxxxxxxx -- 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
