URL:
https://github.com/SSSD/sssd/pull/225
Title: #225: SECRETS: Apply separate quotas for cn=secrets and cn=kcm
simo5 commented:
"""
Yes we need to increase the size per secret, but this is why I am not sure having a
maximum nu,be of secrets will scale well.
If you set the new max to 1MB, and have 256 secreets max then you give 256M of storage per
user ... that seem a lot. On the other hand if you give too few secrets, then a user can
run out o them pretty quickly. Think about a user using secrets to store their browser
keyring, clearly in that case 256 is rather low.
Perhaps we should have different allowed size + # of secrets per hive.
Then the /kcm would have something like 16 secrets allowed but each can be several
megabytes in size, while the regular user space would have a few thousand secrets (4k ?)
allowed but each no more than a few kilobytes in size (say about 16k so that a user can
store large symmetric RSA keys) ?
The other way to use just a size value and allow as many secrets as you want is to use a
"pool of sectors" that can be used to store secrets. Each time you store a
secret, the size is calculated and detracted and runded up to the "sector size"
(say 4k), and that amount is removed from the total allowed size. If that number goes to
zero we return an error. Then when a secret is deleted we have to free up sectors. This
means we have to modify 2 records each time we write to the secrets storage, which may not
be ideal.
There are ways around that though. For example we could write the number of
"sectors" used (or even the size of the value) in the entry itself, and have an
index on this attribute. Keep the size of the per/user data in a hash table in memory and
keep track of quota there. If the daemon is restarted, the user quota is recomputed, the
first time the user makes a write, by searching the database for all user's records
and summing all records, then from there on keep the quota again in memory until the hash
table is full (could be fixed size with FIFO) or the daemon is restarted.
I am sure we can think of other ways, the point is that we should be fair, and it is hard
to privilege number of secrets versus size, because KCM vs passwords vs RSA keys have
quite different per-secret sizes so it would be very difficult to find a balance if we
have ust one quota and we count number of secrets.
"""
See the full comment at
https://github.com/SSSD/sssd/pull/225#issuecomment-304812108