On Thu, May 05, 2016 at 05:01:58PM -0400, Chuck Lever wrote: > After some IRC discussion with Bruce, we think the answer > is "this is not supported in the current Linux NFS server." > > The server does not have a way to determine which service > principal to use for NFSv4.0 callback operations. It picks > (probably) the first nfs/ service principal in the server's > keytab for all callback operations. > > Thus if a Linux NFS server has a keytab, clients can mount > it with NFSv4.0 (and any security flavor) only on the i/f > whose hostname matches the name of the nfs/ service > principal in that server's keytab. One correction: the mount should still work correctly. The server just won't grant any delegations to the client. > In other words, if the server has a keytab with the > principals: > > nfs/server-a > nfs/server-b > nfs/server-c > > NFSv4.0 will operate correctly only when mounting the > server via server-a: . > > Clients that do not have a keytab should be able to mount > with NFSv4.0 via the other interfaces. This is because > they will not try to negotiate krb5i for lease management, > and the server will not attempt to use krb5i for callback > operations. > > Bruce feels this is a corner case, would be difficult to > address, and is adequately worked around by using NFSv3 > or NFSv4.1 or higher. So currently this is a WONTFIX. Right, so if there's somebody really need delegations in the multi-homed NFSv4.0/krb5 case, they're welcomed to look into it--I can't say I'd turn down good patches (maybe it's not even that hard--may depend on whether the gss-proxy protocol does what we need?). But it doesn't seem like a priority. --b. > > Copied Bruce to correct anything I might have summarized > incorrectly. > > -- > 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
