[sssd PR#806][opened] sudo: always use server highest usn for smart refresh
by pbrezina
URL: https://github.com/SSSD/sssd/pull/806
Author: pbrezina
Title: #806: sudo: always use server highest usn for smart refresh
Action: opened
PR body:
"""
The sudo attributes may not be indexed on the server, therefore if
smart refresh filter is run on the server it may first search using
the indexed entryusn attribute and run the rest of the filter on
non-sudo objects. The number of objects that are filtered may increased
dramatically if sudo rules are not changed for a long time (and thus
keeping smaller and smaller last sudo usn number).
This patch makes sure that highest sudo usn number is always set to
the highest server usn number after each refresh.
Resolves:
https://pagure.io/SSSD/sssd/issue/3997
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/806/head:pr806
git checkout pr806
4 years, 11 months
[sssd PR#815][opened] fix to not ignore/drop sudo "defaults" rule
by pzirnik
URL: https://github.com/SSSD/sssd/pull/815
Author: pzirnik
Title: #815: fix to not ignore/drop sudo "defaults" rule
Action: opened
PR body:
"""
The "cn=defaults" rule does not require to have a sudoUser attribute, however with latest changes the defaults rule get dropped because of the missing sudoUser attribute. According to sudo ldap schema the attribute sudoUser is only a MAY not a MUST. Also when using the old pam/nss ldap library this is not an issue. I have seen no "cn=defaults" rule until now that does have a sudoUser attribute set, so i count this as a regression.
My proposed patch does skip sysdb_sudo_add_lowered_users() if the rule name matches "defaults", which looks like the best possible approach for now.
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/815/head:pr815
git checkout pr815
4 years, 11 months