[sssd PR#5407][opened] kcm: check socket path loaded from configuration
by ikerexxe
URL: https://github.com/SSSD/sssd/pull/5407
Author: ikerexxe
Title: #5407: kcm: check socket path loaded from configuration
Action: opened
PR body:
"""
There are three major execution flows for this change:
1. If kcm socket path is not defined in sssd configuration, then log it and fall back to the default location.
2. If kcm socket path is defined in sssd configuration but the location is invalid, then log it and fall back to the default location.
3. If kcm socket path is defined in sssd configuration and the location is valid, then use it.
Apart from that some unit-tests have been implement to check that the changes work as expected.
I wonder if the changes included in confdb_get_string() should be ported to all confdb_get_*() methods.
Resolves: https://github.com/SSSD/sssd/issues/5406
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/5407/head:pr5407
git checkout pr5407
4 days, 13 hours
[sssd PR#5422][opened] Logs review
by alexey-tikhonov
URL: https://github.com/SSSD/sssd/pull/5422
Author: alexey-tikhonov
Title: #5422: Logs review
Action: opened
PR body:
"""
This is a set of patches intended to enable higher log level by default.
Currently I target SSSDBG_OP_FAILURE (level 2) as a default (It seems SSSDBG_MINOR_FAILURE level contains legitimate messages that admin can deliberately ignore, and those messages can get quite spammy)
Perhaps several patches are yet missing (I'm awaiting @sumit-bose response) but those already published are ready for review.
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/5422/head:pr5422
git checkout pr5422
3 weeks, 3 days
[sssd PR#5419][opened] Adding tests to cover ad discovery improvements using cldap
by sidecontrol
URL: https://github.com/SSSD/sssd/pull/5419
Author: sidecontrol
Title: #5419: Adding tests to cover ad discovery improvements using cldap
Action: opened
PR body:
"""
* This test requires a primary and secondary domain controller so AD can be moved between sites
* Currently contains four test cases
** Two DCs in one site no restrictions.
** Two DCs in one site, traffic blocked to the other DC
** DCs in seperate sites no restrictions
** DCs in seperate sites, traffic blocked to the other DC
Signed-off-by: Dan Lavu <dlavu(a)redhat.com>
SSSD-2497
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/5419/head:pr5419
git checkout pr5419
3 weeks, 5 days
[sssd PR#5401][opened] authtok: add label to Smartcard token
by sumit-bose
URL: https://github.com/SSSD/sssd/pull/5401
Author: sumit-bose
Title: #5401: authtok: add label to Smartcard token
Action: opened
PR body:
"""
The key-id might not be sufficient to identify a certificate on a Smartcard
since it is possible that multiple certificates will use the same key.
This patch adds the certificate label to the Smartcard authtok item to
about the ambiguity if the key-id is used for multiple certificates.
Currently the key-id read from the Smartcard is used as key value for the
gdm choice list dialog. Since it might be possible that multiple
certificates use the same key and hence the same key-id this is not a
suitable value.
With this patch the string representation of a numerial counter is used.
Resolves: https://github.com/SSSD/sssd/issues/5400
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/5401/head:pr5401
git checkout pr5401
1 month
[sssd PR#5367][opened] pam: add pam_sss_gss module for gssapi authentication
by pbrezina
URL: https://github.com/SSSD/sssd/pull/5367
Author: pbrezina
Title: #5367: pam: add pam_sss_gss module for gssapi authentication
Action: opened
PR body:
"""
The module configuration and usage should be clear
from its manual page. Suggestions are welcome.
The main use case is to enable password-less authentication
for sudo where smartcards are not possible (because the
reader is not available in the target host).
It is not possible to set the service name or keytab at this
moment so the module relies on `host/hostname@REALM` where hostname
is provided by SSSD (based on the user's domain) and REALM
is determined by GSSAPI. This principal is already stored in
krb5_keytab location for IPA and AD providers so the functionality
is for free.
Because authorization is done by pam_sss and it is not needed
for the use case, I would implement configurable ticket names
and keytab location only when required by users.
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/5367/head:pr5367
git checkout pr5367
1 month
[sssd PR#5375][opened] kcm: improve performance for large ccaches
by pbrezina
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(a)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
1 month, 1 week