Re: NFSv4 idmap misbehavior

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

> 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
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




[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux