@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.
@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: key_and_ link function key_and_ link is passed the *KEY_ALLOC_ IN_QUOTA* flag making it an explicit call to keep the key in the quota
- request_key function is called, which
- calls the internal (not listed in any exported headers) request_
- request_
* nfsidmap executable from the nfs-utils package instantiate_ key function via the syscall interface.
- 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_
- 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.