[SSSD-users] Using sssd sudo with CIDR addressing
I've seem to have noticed a problem with using sssd with LDAP SudoHost's that
contain CIDR addresses.
We break our clusters into subnets and each have a few rules explicitly for those systems
Lets call them
cluster_a 192.168.1.0/24
cluster_b 192.168.2.0/24
cluster_c1 192.168.3.0/25
cluster_c2 192.168.3.128/25
cluster_d 192.168.4.0/23
cluster_f 192.168.6.0/24
...
cluster_z: 192.168.26.0/24
Each one may (or may not) have individual sudoUser / sudoCommand allowing certain groups
access.
So in LDAP for cluster b we have for example
dn: cn=cluster_b,ou=sudoers,dc=EXAMPLE,dc=COM
objectClass: top
objectClass: sudoRole
cn: cluster_root
sudoHost: 192.168.2.0/24
sudoUser: Buser1
sudoUser: Buser2
sudoCommand: su - sap
But then we have few additional sudo rules (mostly for administrators) which encompass
that whole group of clusters:
dn: cn=cluster_all,ou=sudoers,dc=EXAMPLE,dc=COM
objectClass: top
objectClass: sudoRole
cn: cluster_all
sudoHost: 192.168.0.0/19
sudoUser: Admin1
sudoUser: Admin2
sudoCommand: ALL
This worked fine when just using sudo pointing to our ldap server. As sudo apparently on
execution grabs all the rules and figures out if our host is in it. It has been working
like this for us for years.
But it is no longer working now that we are attempting to implement sssd caching. Namely
because sssd sends an ldap query for sudoHost={ALL, current hostname, current IP, and just
the currently used subnet (say 192.168.8.0/24) }. Not all possible larger sub ranges to
which it belongs.
We've worked around it for now by putting in all the various subranges we use, but
that has made the sudo rules in LDAP really messy and worse always subject to change as we
add an delete specialized equipment.
Can someone confirm this behavior?