Comment 115 for bug 1124250

Revision history for this message
In , Dariusz (dariusz-redhat-bugs) wrote :

@Maurizio Paolini: is the fact that the NFS keys *should not* count against the root_maxkeys quota documented anywhere?

I was also expecting this to be outside the quote. I have made some research in the kernel code and here is what I was able to find:

* the keyring is created with the KEY_ALLOC_NOT_IN_QUOTA flag (and the absense of Q flag in /proc/keys confirms that), however

* individual keys are created in nfs_idmap_request_key:
  - request_key function is called, which
  - calls the internal (not listed in any exported headers) request_key_and_link function
  - request_key_and_link is passed the *KEY_ALLOC_IN_QUOTA* flag making it an explicit call to keep the key in the quota

* nfsidmap executable from the nfs-utils package
  - uses a keyctl_instantiate function. The 4th parameter of this function is keyring id and in case of this tool is always 0.
  - I believe the control later enters kernel space in the keyctl_instantiate_key function via the syscall interface.
  - this keyring id is then mapped to an actual in-kernel keyring and the key being mapped (through the nfsidmap commandline) is linked to that keyring. Obviously, if 0 is always passed there it will never happen. On the other hand, patching this issue (locally) has not caused any changes in the quota behaviour.

Summary:
According to current implementation (and my understanding) current behavior is expected. I would be very interested any opinion on this.