the attached patches are the first self-contained part of my performance
work. Using them, I analyzed the performance of 'id' as the worst-case,
then realized most of the issues are around processing and storing large
groups. The results gathered using these scripts are in fact the base of
the improvements documented at:
I tried to add descriptive commit messages to the patches so that hopefully
all the info is in those commit messages. We will probably add more probes
into different areas of code, but these are the ones that I already haven't
modified for weeks, so I think it should be safe to merge them.
The probes are enabled in our RPMs and I would encourage downstreams to
enable them as well. There is virtually no cost of having the probes
compiled in by default and the benefit would be that admins can run them
to see what are the bottlenecks in their environment. I was also
wondering if it makes sense to add a generic back-end-request tracking
probes and an associated script, but since the data provider is being
re-factored at the moment, I think it would be better to land the DP
The reason I split the sysdb probes into several commits (unlike the LDAP
probes) is that I think in future, we can use these commits as a
reference for adding more probes to different areas of SSSD.
(BTW, thanks to Lukas for helping me a lot with the build failures on
#sssd last week)
I took some time to find out why pam-srv-tests fails so often.
It is caused by slow execution of function sysdb_cache_password_ex.
(Thu Jun 9 22:13:36:771048 2016) [sssd] [sysdb_cache_password_ex] (0x0100): start.
(Thu Jun 9 22:13:36:771317 2016) [sssd] [sysdb_cache_password_ex] (0x0100): Before s3crypt_gen_salt
(Thu Jun 9 22:13:36:771678 2016) [sssd] [sysdb_cache_password_ex] (0x0100): Before s3crypt_sha512
(Thu Jun 9 22:13:38:022470 2016) [sssd] [sysdb_cache_password_ex] (0x0100): Before sysdb_new_attrs
(Thu Jun 9 22:13:38:023115 2016) [sssd] [sysdb_cache_password_ex] (0x0100): Before sysdb_attrs_add_string
(Thu Jun 9 22:13:38:023431 2016) [sssd] [sysdb_cache_password_ex] (0x0100): Before sysdb_attrs_add_long
(Thu Jun 9 22:13:38:023829 2016) [sssd] [sysdb_cache_password_ex] (0x0100): Before sysdb_attrs_add_long v2
(Thu Jun 9 22:13:38:024156 2016) [sssd] [sysdb_cache_password_ex] (0x0100): Before sysdb_attrs_add_long v3
(Thu Jun 9 22:13:38:024482 2016) [sssd] [sysdb_cache_password_ex] (0x0100): Before sysdb_attrs_add_uint32
(Thu Jun 9 22:13:38:024816 2016) [sssd] [sysdb_cache_password_ex] (0x0100): Before sysdb_set_user_attr
(Thu Jun 9 22:13:38:035319 2016) [sssd] [sysdb_cache_password_ex] (0x0100): return eok
As you can see, the execution of function s3crypt_sha512
took almost two seconds.
Is it caused by valgrind all low entropy?
I can try to go deeper and find out which part of function sha512_crypt_r
is very slow. But it's faster to write to mailing list rather than
wait for results from CI.
this set of patches should resolve
https://fedorahosted.org/sssd/ticket/2897 "Smart Cards: Certificate in
the ID View" and cover all other use cases from
as well. So basically certificates can be read from IPA and local
overrides and from AD with direct in indirect integration.
The patches are all about lookups, so Smartcards and authentication is
not needed to test them. All is needed is a certificate which can be
added to an AD user object or an override object and then try to lookup
the user with
dbus-send --system --print-reply --dest=org.freedesktop.sssd.infopipe \
from a IPA client, IPA server or AD client with AD provier.
If the certificate is store in the AD user object and the lookup is
started on an IPA client a patch for the IPA server is needed, because
the request has to run via the extdom plugin. I'll send a patch to
freeipa-devel which will use the sss_nss_getnamebycert() call added by
one of the patches to allow the extdom plugin to do lookups by
certificate. This means that SSSD on the IPA server must used the
attached patches as well.
that attached two patches would allow to use the Smartcard support in
gdm with SSSD. To use it you should replace pam_pkcs11 in
/etc/pam.d/smartcard-auth in the auth section by
auth sufficient pam_sss.so allow_missing_name
and drop the password section completely.
To enable the Smartcard support in gdm the easiest way is to use
In the org/gnome/login-screen section you can switch the Smartcard
support on and off. Additionally you might want to tune the removal
action in org/gnome/settings-daemon/peripherals/smartcard .
If now a Smartcard is inserted gdm should register it, call
/etc/pam.d/gdm-smartcard which calls /etc/pam.d/smartcard-auth without a
user name. With the new option from the first patch pam_sss will accept
this and send it to the pam responder. The pam responder can handle this
if Smartcard authentication is enabled, tries to read the certificate
from the Smartcard, tries to find and matching user and if successful,
returns the user name to pam_sss which puts it on the PAM stack and
continues with the authentication.
It would be nice if someone can review the code even without testing the
functionality. In this case I will ask someone else with access to
Smartcards and reader to do some functional testing.
I think these patches are candidates for the pam wrapper based tests
Jakub has for review on the list. I'll start reviewing those and add
tests when they are in master.
this is a bit of a follow-up patch to "subdomains: inherit
ldap_krb5_keytab". It turned out that if the default keytab contains
some completely unrelated keys the SASL initialization might e.g. pick a
wrong realm name because the alternative keytab was only added later
during the initialization.
After a little discussion with Dmitri and Sumit we decided that we'll need
options for controlling session recording in sssd.conf, after all.
The options should be something like this:
record_sessions - string, one of: none/some/all, default is "none"
record_sessions_users - string, space-separated list of users to record
record_sessions_groups - string, space-separated list of groups to record
I'm not sure where we should put them. They can't be put into "nss" or "pam"
sections alone, as they concern both (nss fakes the shell, pam adds enviroment
variables). I would rather put them into the global "sssd" section and have
fully-qualified usernames listed there, but I see that there is very little
options there otherwise, so I suspect they wouldn't be welcome. Otherwise, we
can put them into domain sections, but that would mean duplicating the
"record_sessions" option in every one of them, which is inconvenient.
What do you think about any of the above?
Pavel Březina and I have prepared the 1st draft of design document. We mostly focused on summing up its future functionality and its interface.
Please comment if you miss some essential functionality or if you would prefer some different interface.