URL: https://github.com/SSSD/sssd/pull/5375 Author: pbrezina Title: #5375: kcm: improve performance for large ccaches Action: opened
PR body: """ KCM protocol is not designed for highest performance and our impelmentation contained three huge bottle necks - encryption, json serialization and too much cache access. These are unnecessary - the encryption is meaningless since once you get access to the root-owned cache file you can also access the decryption key so there is no added security. JSON is unneccessarily large, requires base64 encoding of credentials and takes too long to parse. The cache was accessed with each GET_CRED_BY_UUID operation. This operation is called once for each credential when iterating over them.
The iteration over credentials in Kerberos looks like this: ``` // GET_CRED_UUID_LIST - fetch list of credentials and create a cursor krb5_cc_start_seq_get(context, cache, &cur);
// GET_CRED_BY_UUID - get credential by uuid while ((ret = krb5_cc_next_cred(context, cache, &cur, &creds)) == 0) { do_something(creds); krb5_free_cred_contents(context, &creds); }
// destroy the cursor krb5_cc_end_seq_get(context, cache, &cur); ```
I have addressed these bottlenecks and the performance has improved dramatically. The test was to establish security context via GSSAPI with 200 services using [this testing app](https://github.com/pbrezina/gssapi-auth).
``` # run gssapi server ../gssapi-auth-server -s socket -k test.keytab &
# get service tickets for i in $(seq 1 200); do ../gssapi-auth-client -s socket -n test$i@master.client.vm ; done
# terminate server pkill gssapi-auth-server ```
Here are the results:
| memory | secdb | keyring -------------------------------------------- before | 19m59.713s | 33m41.337s | after | 1m50.610s | 1m55.496s | 0m2.643s
It is still pretty slow in comparison with keyring. The next bottleneck is communication over the socket. Keyring stores list of credentials directly in the cursor so `krb5_cc_next_cred` returns data immediately without calling to the keyring. We should do the same in KCM however this requires changes in the KCM protocol and needs to be communicated with its upstream.
Resolves: https://github.com/SSSD/sssd/issues/5349 """
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/5375/head:pr5375 git checkout pr5375
URL: https://github.com/SSSD/sssd/pull/5375 Author: pbrezina Title: #5375: kcm: improve performance for large ccaches Action: edited
Changed field: body Original value: """ KCM protocol is not designed for highest performance and our impelmentation contained three huge bottle necks - encryption, json serialization and too much cache access. These are unnecessary - the encryption is meaningless since once you get access to the root-owned cache file you can also access the decryption key so there is no added security. JSON is unneccessarily large, requires base64 encoding of credentials and takes too long to parse. The cache was accessed with each GET_CRED_BY_UUID operation. This operation is called once for each credential when iterating over them.
The iteration over credentials in Kerberos looks like this: ``` // GET_CRED_UUID_LIST - fetch list of credentials and create a cursor krb5_cc_start_seq_get(context, cache, &cur);
// GET_CRED_BY_UUID - get credential by uuid while ((ret = krb5_cc_next_cred(context, cache, &cur, &creds)) == 0) { do_something(creds); krb5_free_cred_contents(context, &creds); }
// destroy the cursor krb5_cc_end_seq_get(context, cache, &cur); ```
I have addressed these bottlenecks and the performance has improved dramatically. The test was to establish security context via GSSAPI with 200 services using [this testing app](https://github.com/pbrezina/gssapi-auth).
``` # run gssapi server ../gssapi-auth-server -s socket -k test.keytab &
# get service tickets for i in $(seq 1 200); do ../gssapi-auth-client -s socket -n test$i@master.client.vm ; done
# terminate server pkill gssapi-auth-server ```
Here are the results:
| memory | secdb | keyring -------------------------------------------- before | 19m59.713s | 33m41.337s | after | 1m50.610s | 1m55.496s | 0m2.643s
It is still pretty slow in comparison with keyring. The next bottleneck is communication over the socket. Keyring stores list of credentials directly in the cursor so `krb5_cc_next_cred` returns data immediately without calling to the keyring. We should do the same in KCM however this requires changes in the KCM protocol and needs to be communicated with its upstream.
Resolves: https://github.com/SSSD/sssd/issues/5349 """
URL: https://github.com/SSSD/sssd/pull/5375 Title: #5375: kcm: improve performance for large ccaches
pbrezina commented: """ The test scenario seems like something artificial but it is actually exactly what happens in [RHBZ#1876514](https://bugzilla.redhat.com/show_bug.cgi?id=1876514). The customer has large number of hosts managed by ansible and gssapi authentication is used instead of password or certificate so it generates large amount of tickets. """
See the full comment at https://github.com/SSSD/sssd/pull/5375#issuecomment-715412325
URL: https://github.com/SSSD/sssd/pull/5375 Author: pbrezina Title: #5375: kcm: improve performance for large ccaches Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/5375/head:pr5375 git checkout pr5375
URL: https://github.com/SSSD/sssd/pull/5375 Title: #5375: kcm: improve performance for large ccaches
simo5 commented: """ Nice work! """
See the full comment at https://github.com/SSSD/sssd/pull/5375#issuecomment-715530897
URL: https://github.com/SSSD/sssd/pull/5375 Author: pbrezina Title: #5375: kcm: improve performance for large ccaches Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/5375/head:pr5375 git checkout pr5375
URL: https://github.com/SSSD/sssd/pull/5375 Author: pbrezina Title: #5375: kcm: improve performance for large ccaches Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/5375/head:pr5375 git checkout pr5375
URL: https://github.com/SSSD/sssd/pull/5375 Title: #5375: kcm: improve performance for large ccaches
pbrezina commented: """
My major concern is whether the binary format is documented somewhere? I'm not seeing it here.
It's internal format and the code is quite straightforward, so I'd say the code is a documentation and I don't have the need to document it elsewhere.
I addressed your requests. There is an error in integration tests that seems to be a valid bug that needs to be addressed. I'm looking into it.
"""
See the full comment at https://github.com/SSSD/sssd/pull/5375#issuecomment-717392447
URL: https://github.com/SSSD/sssd/pull/5375 Author: pbrezina Title: #5375: kcm: improve performance for large ccaches Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/5375/head:pr5375 git checkout pr5375
URL: https://github.com/SSSD/sssd/pull/5375 Author: pbrezina Title: #5375: kcm: improve performance for large ccaches Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/5375/head:pr5375 git checkout pr5375
URL: https://github.com/SSSD/sssd/pull/5375 Author: pbrezina Title: #5375: kcm: improve performance for large ccaches Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/5375/head:pr5375 git checkout pr5375
URL: https://github.com/SSSD/sssd/pull/5375 Title: #5375: kcm: improve performance for large ccaches
pbrezina commented: """ Ok, tests should pass now, it is ready for a new review.
There was a problem with kvno which is fixed by patch: `sss_ptr_hash: fix double free for circular dependencies`. The problem was in case where the same connection iterated over the credentials which caused the hash table corruption when overriding an existing entry.
There where two quota related failures - one in secrets responder which was off by one error because the payload size did not contain ending zero previously but now it does. The other was in kcm multihost tests just because the new binary format takes much less data so having just TGT in the ccache was not enough to exceed 1KiB limit. I call kinit now which aquires TGT + control credentials which exceeds this limit.
I tried to use `kvno host/...` to do that but there may be a bug in libkrb5. When kvno stored the service ticket, KCM returned `KRB5_FCC_INTERNAL` because the limit was exceeded and the service ticket was not stored in the ccache. However `kvno` still printed the principal information `host/master.client.vm@EXAMPLE.TEST: kvno = 2` and exited with 0. I believe it is expected to fail? """
See the full comment at https://github.com/SSSD/sssd/pull/5375#issuecomment-721210321
URL: https://github.com/SSSD/sssd/pull/5375 Title: #5375: kcm: improve performance for large ccaches
Label: +Waiting for review
URL: https://github.com/SSSD/sssd/pull/5375 Author: pbrezina Title: #5375: kcm: improve performance for large ccaches Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/5375/head:pr5375 git checkout pr5375
URL: https://github.com/SSSD/sssd/pull/5375 Title: #5375: kcm: improve performance for large ccaches
pbrezina commented: """ Tests pass. The failure on rawhide is due to https://github.com/SSSD/sssd/issues/5385 """
See the full comment at https://github.com/SSSD/sssd/pull/5375#issuecomment-721779993
URL: https://github.com/SSSD/sssd/pull/5375 Title: #5375: kcm: improve performance for large ccaches
alexey-tikhonov commented: """ Covscan error: ``` Error: CONSTANT_EXPRESSION_RESULT (CWE-569): sssd-2.4.1/src/responder/kcm/kcmsrv_ops.c:1398: logical_vs_bitwise: The expression "ret != 0 && ERR_NO_CREDS" is suspicious because it performs a Boolean operation on a constant other than 0 or 1. sssd-2.4.1/src/responder/kcm/kcmsrv_ops.c:1398: remediation: Did you intend to also compare "ret" to "ERR_NO_CREDS"? # 1396| } else { # 1397| ret = kcm_op_get_cred_by_uuid_reply(crd, state->common.op_ctx->reply); # 1398|-> if (ret != EOK && ERR_NO_CREDS) { # 1399| tevent_req_error(req, ret); # 1400| return; ``` """
See the full comment at https://github.com/SSSD/sssd/pull/5375#issuecomment-733062809
URL: https://github.com/SSSD/sssd/pull/5375 Title: #5375: kcm: improve performance for large ccaches
alexey-tikhonov commented: """ Covscan error: ``` Error: CONSTANT_EXPRESSION_RESULT (CWE-569): sssd-2.4.1/src/responder/kcm/kcmsrv_ops.c:1398: logical_vs_bitwise: The expression "ret != 0 && ERR_NO_CREDS" is suspicious because it performs a Boolean operation on a constant other than 0 or 1. sssd-2.4.1/src/responder/kcm/kcmsrv_ops.c:1398: remediation: Did you intend to also compare "ret" to "ERR_NO_CREDS"? # 1396| } else { # 1397| ret = kcm_op_get_cred_by_uuid_reply(crd, state->common.op_ctx->reply); # 1398|-> if (ret != EOK && ERR_NO_CREDS) { # 1399| tevent_req_error(req, ret); # 1400| return; ```
Suspicious indeed... """
See the full comment at https://github.com/SSSD/sssd/pull/5375#issuecomment-733062809
URL: https://github.com/SSSD/sssd/pull/5375 Title: #5375: kcm: improve performance for large ccaches
alexey-tikhonov commented: """ Ouch... This is really large!
I have to re-read "kcm: store credentials list in hash table to avoid cache lookups " and "sss_ptr_hash: fix double free for circular dependencies" patches. Btw, don't you think it makes sense to factor out the latter into stand alone PR? It would create additional hustle while backporting patches downstream, but that looks like separate bugfix.
I've left a number of comments inline. Of those I'd like to highlight default hash table size and covscan error.
Besides that my main and most important question is as follows: Is it really worth the trouble to keep backward compatibility for the sake of existing ccaches? That's quite a pile of code to support JSON format in kcm and encrypted payload in "secdb"... We could simplify things a lot by dropping enc_type and data_type entirely (perhaps alongside with secrets responder and even parts of util/crypto). I can imagine you have different view since you already put this effort in. But is it at least something we could consider for a future release, when old format user ccaches should be expired?
"""
See the full comment at https://github.com/SSSD/sssd/pull/5375#issuecomment-733260458
URL: https://github.com/SSSD/sssd/pull/5375 Title: #5375: kcm: improve performance for large ccaches
alexey-tikhonov commented: """ Could you please explain clain "2)" in the "sss_ptr_hash: fix double free for circular dependencies" patch?
Even taking into account `sss_ptr_hash_value` was created in the context of `payload`, I still see no problem if custom cb deletes `payload` in this execution flow: `libtalloc` will not enter `sss_ptr_hash_value_destructor` recursively (or what other reason for "crash in talloc" you expect?) I think existing test `test_sss_ptr_hash_with_free_cb` covers this. Or do I miss something? """
See the full comment at https://github.com/SSSD/sssd/pull/5375#issuecomment-733275701
URL: https://github.com/SSSD/sssd/pull/5375 Title: #5375: kcm: improve performance for large ccaches
alexey-tikhonov commented: """ Could you please explain claim "2)" in the "sss_ptr_hash: fix double free for circular dependencies" patch?
Even taking into account `sss_ptr_hash_value` was created in the context of `payload`, I still see no problem if custom cb deletes `payload` in this execution flow: `libtalloc` will not enter `sss_ptr_hash_value_destructor` recursively (or what other reason for "crash in talloc" you expect?) I think existing test `test_sss_ptr_hash_with_free_cb` covers this. Or do I miss something? """
See the full comment at https://github.com/SSSD/sssd/pull/5375#issuecomment-733275701
URL: https://github.com/SSSD/sssd/pull/5375 Title: #5375: kcm: improve performance for large ccaches
pbrezina commented: """
Ouch... This is really large!
Thank you for thorough review. You did an excellent job.
I have to re-read "kcm: store credentials list in hash table to avoid cache lookups " and "sss_ptr_hash: fix double free for circular dependencies" patches. Btw, don't you think it makes sense to factor out the latter into stand alone PR? It would create additional hustle while backporting patches downstream, but that looks like separate bugfix.
It is required for this patch set to work correctly, otherwise some use cases are broken (`kvno` command will fail), so it needs to stay bound to this PR. However, as far as I can tell, it is not needed by other uses of `sss_ptr_hash`.
I've left a number of comments inline. Of those I'd like to highlight default hash table size and covscan error.
Thank you. Those that were fixed are marked as resolved.
Besides that my main and most important question is as follows: Is it really worth the trouble to keep backward compatibility for the sake of existing ccaches? That's quite a pile of code to support JSON format in kcm and encrypted payload in "secdb"... We could simplify things a lot by dropping enc_type and data_type entirely (perhaps alongside with secrets responder and even parts of util/crypto). I can imagine you have different view since you already put this effort in. But is it at least something we could consider for a future release, when old format user ccaches should be expired?
You are completely correct. It is mostly needed to keep compatibility with secrets responder and we got smooth upgrade without the need to re-run kinit almost for free which is nice. I'm definitely pro dropping secrets code but I didn't want to do this as part of this PR.
Could you please explain claim "2)" in the "sss_ptr_hash: fix double free for circular dependencies" patch?
Honestly, I can not. I already forgot the details and it is not directly reproducable. The reproducer was to run `kvno` to obtain a service ticket. It called `GET_CRED_UUID_LIST` several times on the same connection so with hit `kcm_creds_to_table()` multiple times on non-empty table (which is perfectly valid case as the comment describes). This lead to the first issue, when hash_delete(old) was called from hasn_enter() to overwrite existing entry. I hit the second issue (crash in talloc) with few non-final patches for the first issue so I can't tell you how to reproduce. There was some catch in it bound to the fact that an entry is being overwritten. I can remove it from the description if you want?
"""
See the full comment at https://github.com/SSSD/sssd/pull/5375#issuecomment-734270404
URL: https://github.com/SSSD/sssd/pull/5375 Author: pbrezina Title: #5375: kcm: improve performance for large ccaches Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/5375/head:pr5375 git checkout pr5375
URL: https://github.com/SSSD/sssd/pull/5375 Title: #5375: kcm: improve performance for large ccaches
alexey-tikhonov commented: """
Could you please explain claim "2)" in the "sss_ptr_hash: fix double free for circular dependencies" patch?
Honestly, I can not. I already forgot the details and it is not directly reproducable. The reproducer was to run `kvno` to obtain a service ticket. It called `GET_CRED_UUID_LIST` several times on the same connection so with hit `kcm_creds_to_table()` multiple times on non-empty table (which is perfectly valid case as the comment describes). This lead to the first issue, when hash_delete(old) was called from hasn_enter() to overwrite existing entry. I hit the second issue (crash in talloc) with few non-final patches for the first issue so I can't tell you how to reproduce. There was some catch in it bound to the fact that an entry is being overwritten. I can remove it from the description if you want?
I agree that `overwriting existing entry` results in double `hash_delete()` if custom delete_cb calls talloc_free(payload). I'm not sure if `delete_in_progress` is the best way to deal with it (can't propose anything better atm), but I agree this check in `sss_ptr_hash_delete_cb` resolves this issue.
With regards to additional check in `sss_ptr_hash_value_destructor`: I think it's not required (and test added by you runs fine without this check). But taking into account comment text along this check - I'm ok with it.
Nonetheless, I still think part (2) of commit message is confusing so if not possible to update, I would propose to delete it. (Wrt to potential for a crash: if one sets both custom_cb that calls `talloc_free()` **and** calls `sss_ptr_hash_delete(free_value=true)` -- it gonna crash on double-free, I think. But this is wrong usage and patch doesn't prevent this anyway.) """
See the full comment at https://github.com/SSSD/sssd/pull/5375#issuecomment-736784240
URL: https://github.com/SSSD/sssd/pull/5375 Title: #5375: kcm: improve performance for large ccaches
alexey-tikhonov commented: """
Could you please explain claim "2)" in the "sss_ptr_hash: fix double free for circular dependencies" patch?
Honestly, I can not. I already forgot the details and it is not directly reproducable. The reproducer was to run `kvno` to obtain a service ticket. It called `GET_CRED_UUID_LIST` several times on the same connection so with hit `kcm_creds_to_table()` multiple times on non-empty table (which is perfectly valid case as the comment describes). This lead to the first issue, when hash_delete(old) was called from hasn_enter() to overwrite existing entry. I hit the second issue (crash in talloc) with few non-final patches for the first issue so I can't tell you how to reproduce. There was some catch in it bound to the fact that an entry is being overwritten. I can remove it from the description if you want?
I agree that `overwriting existing entry` results in double `hash_delete()` if custom delete_cb calls talloc_free(payload). I'm not sure if `delete_in_progress` is the best way to deal with it (can't propose anything better atm), but I agree this check in `sss_ptr_hash_delete_cb` resolves this issue.
With regards to additional check in `sss_ptr_hash_value_destructor`: I think it's not required (and test added by you runs fine without this check). But taking into account comment text along this check - I'm ok with it.
Nonetheless, I still think part (2) of commit message is confusing so if not possible to update, I would propose to delete it. """
See the full comment at https://github.com/SSSD/sssd/pull/5375#issuecomment-736784240
URL: https://github.com/SSSD/sssd/pull/5375 Title: #5375: kcm: improve performance for large ccaches
alexey-tikhonov commented: """
Could you please explain claim "2)" in the "sss_ptr_hash: fix double free for circular dependencies" patch?
Honestly, I can not. I already forgot the details and it is not directly reproducable. The reproducer was to run `kvno` to obtain a service ticket. It called `GET_CRED_UUID_LIST` several times on the same connection so with hit `kcm_creds_to_table()` multiple times on non-empty table (which is perfectly valid case as the comment describes). This lead to the first issue, when hash_delete(old) was called from hasn_enter() to overwrite existing entry. I hit the second issue (crash in talloc) with few non-final patches for the first issue so I can't tell you how to reproduce. There was some catch in it bound to the fact that an entry is being overwritten. I can remove it from the description if you want?
I agree that `overwriting existing entry` results in double `hash_delete()` if custom delete_cb calls talloc_free(payload). I'm not sure if `delete_in_progress` is the best way to deal with it (can't propose anything better atm), but I agree this check in `sss_ptr_hash_delete_cb` resolves this issue.
With regards to additional check in `sss_ptr_hash_value_destructor`: I think it's not required (and test added by you runs fine without this check). But taking into account comment text along this check - I'm ok with it.
Nonetheless, I still think part (2) of commit message is confusing so if not possible to update, I would propose to delete it.
---
Besides that, there are 6 open minor questions/remarks inline. And it's almost done. """
See the full comment at https://github.com/SSSD/sssd/pull/5375#issuecomment-736784240
URL: https://github.com/SSSD/sssd/pull/5375 Title: #5375: kcm: improve performance for large ccaches
alexey-tikhonov commented: """
From dhash documentation: "The count parameter allows for some more optimization, however it's not critical to get it right, the table will still perform well. If you have no idea of how many entries to expect then pass 0, a reasonable default will be selected.".
JFTR: right, "0" seems to be very good choice: see https://github.com/SSSD/sssd/issues/5134#issuecomment-737443576 and the next comment. """
See the full comment at https://github.com/SSSD/sssd/pull/5375#issuecomment-737453271
URL: https://github.com/SSSD/sssd/pull/5375 Title: #5375: kcm: improve performance for large ccaches
Label: +Changes requested
URL: https://github.com/SSSD/sssd/pull/5375 Title: #5375: kcm: improve performance for large ccaches
Label: -Waiting for review
URL: https://github.com/SSSD/sssd/pull/5375 Author: pbrezina Title: #5375: kcm: improve performance for large ccaches Action: synchronized
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/5375/head:pr5375 git checkout pr5375
URL: https://github.com/SSSD/sssd/pull/5375 Title: #5375: kcm: improve performance for large ccaches
pbrezina commented: """ See new changes. All the comments should be addressed, expect forward declaration.
From dhash documentation: "The count parameter allows for some more optimization, however it's not critical to get it right, the table will still perform well. If you have no idea of how many entries to expect then pass 0, a reasonable default will be selected.".
JFTR: right, "0" seems to be very good choice: see [#5134 (comment)](https://github.com/SSSD/sssd/issues/5134#issuecomment-737443576) and the next comment.
This is very interesting. We can certainly change default value in `sss_ptr_hash` if it has such effect.
"""
See the full comment at https://github.com/SSSD/sssd/pull/5375#issuecomment-738009743
URL: https://github.com/SSSD/sssd/pull/5375 Title: #5375: kcm: improve performance for large ccaches
alexey-tikhonov commented: """ Thanks for patience addressing my pedantic remarks. ACK. """
See the full comment at https://github.com/SSSD/sssd/pull/5375#issuecomment-738168005
URL: https://github.com/SSSD/sssd/pull/5375 Title: #5375: kcm: improve performance for large ccaches
Label: -Changes requested
URL: https://github.com/SSSD/sssd/pull/5375 Title: #5375: kcm: improve performance for large ccaches
Label: +Waiting for review
URL: https://github.com/SSSD/sssd/pull/5375 Title: #5375: kcm: improve performance for large ccaches
Label: -Waiting for review
URL: https://github.com/SSSD/sssd/pull/5375 Title: #5375: kcm: improve performance for large ccaches
Label: +Accepted
URL: https://github.com/SSSD/sssd/pull/5375 Title: #5375: kcm: improve performance for large ccaches
Label: +Ready to push
URL: https://github.com/SSSD/sssd/pull/5375 Title: #5375: kcm: improve performance for large ccaches
pbrezina commented: """ Pushed PR: https://github.com/SSSD/sssd/pull/5375
* `master` * 325de5a5bb97ba026be6d22492bea8ab2605f1b5 - secrets: remove base64 enctype * 39277cdadd317b0ab86cdd37de0616bc3eecbe6a - secrets: move attrs names to macros * 9c1b51d057390fb5b26151f814a480911cda4cc9 - secrets: default to "plaintext" if "enctype" attr is missing * bf127d4f3f42e5b2afe25e512211439bc12a9904 - secrets: fix may_payload_size exceeded debug message * c3b314db57c34f64aaca7d74e76a9a955288bb51 - kcm: store credentials list in hash table to avoid cache lookups * a370553c90c2ed6df3b94c169c4960a6f978031f - sss_ptr_hash: fix double free for circular dependencies * 241ee30da12f564803793ee2b14c1522aabd9235 - kcm: add per-connection data to be shared between requests * 194447d35c11eb914f54719491dc5cfaab01b9a1 - kcm: use binary format to store ccache instead of json * f17740d831e16449495fff4ec57cc4800aaac83d - kcm: add spaces around operators in kcmsrv_ccache_key.c * 15069a647ed6c7f1ead42baa1d421d953c9bc557 - kcm: avoid suppression of cppcheck warning * e63a15038ac9c186626e4fdf681a6492031d1e40 - kcm: move sec key parser to separate file so it can be shared * 9b1631defdcaa3ea7e87889eb136e7fa935ab4ce - kcm: add json suffix to existing searialization functions * b6cc661b9f4162e590137430e945aa321fc13121 - iobuf: add more iobuf functions * ed08ba0023e63024bf1c52ae3f6596b9d804d0a5 - secrets: accept binary data instead of string * 908c15af9a9f8f0556a588e368e4a0b2e24ace1b - secrets: allow to specify secret's data format * 74fdaa64b27e88a6e0f153f8cb59989c572d4294 - kcm: avoid multiple debug messages if sss_sec_put fails * b8f28d9aa9d862cf504691c9c3f92941a63fb0a4 - kcm: disable encryption * 8edcea8c377e85d037e83065c1904fa4b92c4a39 - kcm: avoid name confusion in GET_CRED_UUID_LIST handlers * 47a316c850107f12d406f27abb216e26383dfab7 - kcm: fix typos in debug messages
"""
See the full comment at https://github.com/SSSD/sssd/pull/5375#issuecomment-738711928
URL: https://github.com/SSSD/sssd/pull/5375 Title: #5375: kcm: improve performance for large ccaches
Label: +Pushed
URL: https://github.com/SSSD/sssd/pull/5375 Title: #5375: kcm: improve performance for large ccaches
Label: -Accepted
URL: https://github.com/SSSD/sssd/pull/5375 Title: #5375: kcm: improve performance for large ccaches
Label: -Ready to push
URL: https://github.com/SSSD/sssd/pull/5375 Author: pbrezina Title: #5375: kcm: improve performance for large ccaches Action: closed
To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/5375/head:pr5375 git checkout pr5375
sssd-devel@lists.fedorahosted.org