On Oct 27, 2014, at 10:44 AM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > Hi David- > > On Oct 27, 2014, at 6:32 AM, David Howells <dhowells@xxxxxxxxxx> wrote: > >> Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: >> >>> After the test has been running for ten minutes, the id_resolv >>> keys expire, and id_legacy keys appear. Before the above commit, >>> the id_resolv keys would simply be refreshed and operation >>> would continue normally. >>> >>> # grep id_ /proc/keys >>> 00f0a664 I--Q-N- 1 42s 3b010000 0 0 id_legacy uid:cel@xxxxxxxxxx >> >> The 'N' flag indicates that the key is negatively instantiated - ie. the >> upcall to instantiate them failed in some way. Keys so marked will cause key >> lookups to return ENOKEY (or maybe some other error if keyctl_reject() was >> used). >> >> Failure can be due to the key being properly negatively instantiated >> (keyctl_negate() or keyctl_reject()) or the userspace side of instantiation >> exiting or otherwise dying before it managed to instantiate the key. >> >> Is there anything to actually process the id_legacy upcall? It appears >> they're all negatively instantiated. > > rpc.idmapd isn’t running on this system, so no. Legacy idmapping is > normally disabled on EL6 update 4 AFAICT. > > There is an /etc/request-key.d/id_resolver.conf file, and > /usr/sbin/nfsidmap is there. On another system I previously tried > using only rpc.idmapd, and it didn’t resolve the sudden ownership > change issue. > > There should be no reason to switch to using the legacy ID mapper > upcall if the key resolution infrastructure is working. Before the > “KEYS: Expand the capacity . . . ” commit, id_legacy keys do not > appear in /proc/keys. > > That leads me to believe something that commit did is preventing > expired id_resolv keys from getting renewed. > >> Can you stick "#define __KDEBUG" at the top of security/keys/request_key.c, >> rebuild and look in dmesg? > > Thanks, I’ll give that a try and report back. I enabled __KDEBUG. There are no new messages in /var/log/messages when the reproducer fails. >> Also, /sbin/request-key logs to syslog if it can't find a match in its config >> file. > > I didn’t see any relevant messages in /var/log/messages, but I may > have overlooked something. > > More recent kernels change the key resolver interface to require > key_revoke instead of key_invalidate. I’ve seen /var/log/messages > complaints about that on other EL6 systems running kernels newer > than 3.16. -- 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
