to help the OpenSCAP integration, I prepared a wiki page that contains
options which have a security impact -- either positive (drop root) or
negative (ignore certificate validation issues).
I also tried to explain the effect of the options along with the
description. There are some more items that can be included, but I
wasn't sure about them myself, like:
* should obfuscated passwords be mentioned? I wasn't sure because on
one hand it really doesn't provide any benefit, on the other hand,
the option can be used to check a compliance box that requires no
passwords be stored in files..
* should the page warn against the
auth-option-that-shall-not-be-mentioned or politely deny its
* What about fd_limit ? Should resource consumption be considered
a security property, especially if we already honor system default? I
think here the default is enough, so I didn't document that option.
Please provide your comments or edit the wiki directly. Thanks!
Use extra flag also in OOB request.
Provide support for UPN. This add an improvement from NSS code, but I'm
not sure if it is desired or not.
If you have [domain/AD.PB] in sssd.conf and UPN "upn(a)ad.pb" then NSS
responder will not find this user, cache_req will. Is this nss behavior
intentional or a bug?
I got really sick of the way new test are written in cache_req when
writing new tests so I kinda rewrote it.
I was reprodicing other bug and it took me some time to find out why I was not
able to resolve user. RID was bigger than range size.
I saw just general message about id mapping failer
[sdap_save_user] (0x0400): Processing user matthewbe
[sdap_save_user] (0x1000): Mapping user [matthewbe] objectSID
[S-1-5-21-2997650941-1802118864-3094776726-200065] to unix ID
[sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID
[S-1-5-21-2997650941-1802118864-3094776726-200065] to a UNIX ID
Default range size is 200000
[sdap_save_user] (0x0020): Failed to save user [matthewbe]
[sdap_save_users] (0x0040): Failed to store user 0. Ignoring.
Feel free to propose better debug message. I think it would simplify debugging.
Hi guys, I spent some time working at this ticket
https://fedorahosted.org/sssd/ticket/1108 and I think it's finally
ready to be reviewed by others.
Description of the problem and scope of the changes can be found in
the commit message. I also wrote some unit tests but the patch is a
quite long already so I think it would be better to send the tests as
an another patch. Or should I create a patch for each modified file?
as we're stabilizing the 1.13 branch and before we plan what we want to
work on during the 1.14 development, we should use that time to write
some more tests!
Here are some areas where we could add tests. Please discuss or add your
ideas, I would like to turn this list into tickets we can start
* Extend the LDAP provider tests with more dynamic test cases.
- add a user to a group, run sss_cache, assert id user displays the
new group and getent group displays the new member
- conversely with removing users from groups
* Background refresh
- could be built atop the LDAP NSS tests as well. I think we have
all the infrastructure in place.
* Local overrides integration test:
- this could be relatively easy, just call the overrides tool and
request the entry. Could be built atop the existing LDAP tests
or even use the local provider.
* Add a KDC
- until we have a pam_wrapper, this would only be useful to test
ldap_child, but adding the KDC instantiation might be worth it
- there is a protorype of KDC instantiation on the list for some
time now, since we enabled rootless SSSD
* IFP - could we reuse the existing sbus tests to spawn a custom bus?
* SUDO - can we trick sudo into connecting to our test sssd instance?
I think the order of priority is roughly as above. I think the LDAP
provider is critical enough to be well tested. The refresh and local
override tests might be nice to have because we would be refactoring the
NSS responder in 1.14, so we should have it tested.
I'll be happy to hear other opionions, though!
I noticed one little thing was wrong with the combined
filter_users/filter_groups description on the sssd.conf(5) manpage and also
wanted to add a note WRT nested groups behavior with filter_groups which was a
bit surprising to me. The trivial patches are attached.