[ Replying to my earlier post ] On Oct 30, 2014, at 11:31 AM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > > On Oct 30, 2014, at 10:53 AM, Benjamin Coddington <bcodding@xxxxxxxxxx> wrote: > >> >> On Wed, 29 Oct 2014, Chuck Lever wrote: >> >>> Hi Ben- >>> >>> I’m not sure keyctl_revoke and keyctl_invalidate do >>> precisely the same thing, though? On older systems can >>> we expect a change from one to the other to have no >>> impact? (Just beginning to explore this issue). >> >> For EL6 kernels, you should be good with keyctl_revoke. That's the only >> thing you can do - there's no key_invalidate. >> >> But on later kernels, you'd want to use key_invalidate. > > I realize that EL6 user space is not designed to support > newer kernels, but some distributions allow continuous > upgrades of kernels. If the kernel API changes over time, > then IMO user space tools need to be sensitive to what > kernel is running. > >> The details of the kernel changes are here: >> >> 0c7774abb41bd00d KEYS: Allow special keys (eg. DNS results) to be >> invalidated by CAP_SYS_ADMIN > > I think this means the EL6 nfsidmap no longer works quite > right when running 3.17. I’m still studying the problem. > See below. > >> The summary is that permission changes in later kernels cause >> keyctl_revoke to be unable to clean up keys that are not in possession. >> This specific commit allows that once more for CAP_SYS_ADMIN, so >> really, it should work fine if you have this. However: >> >> keyctl_revoke waits key_gc_timeout to clean up the key, and access >> attempts return -EKEYREVOKED. >> >> keyctl_invalidate immediately removes all references to the key. > > This change means keyctl_set_timeout fails, since > lookup_user_key returns -EKEYREVOKED, for example, when a > key is revoked instead of invalidated. The key timeouts > are then set to 0 (the default). Well, I forgot about the original problem I started seeing with 3.17 on EL6, due to the commit you cited above: Oct 30 11:50:52 dali nfsidmap[2547]: key: 0x23eee41 type: gid value: users@xxxxxxxxxx timeout 600 Oct 30 11:50:52 dali nfsidmap[2547]: adding new child .id_resolver_child_1: Operation not permitted Oct 30 11:50:52 dali nfsidmap[2547]: Failed to add child keyring: Operation not permitted >>> When installing a newer kernel causes a fallback to rpc.idmapd, >>> is there any risk of an ID mapper behavior change? Loss of >>> functionality, for example? >> >> The functionality should be equivalent - I think they end up in the same >> library after making it through the callout/callup interface. >> >> The newer kernels only do the request-key callout, and rpc.idmapd >> won't ever be consulted. > > Unless nfsidmap is broken by a new kernel API. :-) Which is indeed what happens: nfsidmap fails due to the new permissions requirement, and the kernel falls back to using rpc.idmapd. If rpc.idmapd is disabled, not installed, or not provided, and nfsidmap can’t be upgraded to use keyctl_invalidate, then NFSv4 ID mapping will break when 3.17 is installed. Maybe that’s a regression? Or just a gray area . . . -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- 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
