URL:
https://github.com/SSSD/sssd/pull/225
Title: #225: SECRETS: Apply separate quotas for cn=secrets and cn=kcm
jhrozek commented:
"""
After some discussion with @simo5 on IRC, I prepared quite different patches. So far they
don't address the per-client/per-UID quotas. What is implemented so far is that the
quotas can now be set in a per-hive section, for example:
```
[secrets]
# Some generic responder configuration
[secrets/secrets]
max_secrets = 123
max_payload_size = 456
[secrets/kcm]
max_secrets = 345
max_payload_size = 5678
```
Now, the questions I'm wondering are:
* Is this configuration admin-friendly? Should we explicitly add `quota` to the
subsection? (i.e. `[secrets/secrets/quota]` ?
* does it make sense to add a per-uid limit? Something like `max_user_secrets`? Note that
the payload size is already per-secret, so it doesn't count the global secret size. I
assume the answer here is yes, just to avoid starving the store by one malicious user
* The KCM defaults are pulled out of thin air, but they are 256 secrets and the secrets
size is 64MB. This is because one credential in keyring could be up to 1MB and the secret
consists of all credentials in a ccache, so this gives us a little less (because of
encoding) than 64 credentials by default.
The documentation is not yet adjusted, I'd like to do that once we agree on the format
etc to avoid redoing the work. But the tests are there..
"""
See the full comment at
https://github.com/SSSD/sssd/pull/225#issuecomment-304908921