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. Can you stick "#define __KDEBUG" at the top of security/keys/request_key.c, rebuild and look in dmesg? Also, /sbin/request-key logs to syslog if it can't find a match in its config file. David -- 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
