[RFC] SDAP: allow picking up local gid for groups

[eqvinox]

this is a draft PR, soliciting input on whether/how this is desirable as an SSSD feature

This adds 2 config options to the LDAP provider:

ldap_group_absent_gid_local = <bool>
ldap_group_negative_gid_local = <bool>

If the LDAP result for a group's gid is either absent or negative respectively, the code checks whether the group exists in /etc/group, and if it does uses the gid found there.

The point is getting the ability to assign e.g. audio bluetooth etc. groups to users.

I have tested this, but before adding the config options (no idea if I did that right); the current version is untested. It also needs some search filter adjustments for the "absent" case since those groups are otherwise filtered out before this code is reached at all.

[eqvinox]

Looks like I didn't get the config bits right, but… eh. For the time being, I only care about general feedback, polishing can come later.

[alexey-tikhonov]

The point is getting the ability to assign e.g. audio bluetooth etc. groups to users.

Could you please describe use case in a greater details?

Currently it's already possible to add "remote" (LDAP) user to /etc/group and use [SUCCESS=merge] syntax in 'nsswitch.conf' to make remote users to be members of local groups.

[eqvinox]

Currently it's already possible to add "remote" (LDAP) user to /etc/group and use [SUCCESS=merge] syntax in 'nsswitch.conf' to make remote users to be members of local groups.

Yes, but you have to do that on every single system, and keep updating it for new/removed users; membership for these "system local" groups can't be provided by LDAP (unless I've seriously missed something somewhere in the docs?)

With this change, I'm doing this:

dn: cn=libvirt,ou=groups,dc=example,dc=org
objectClass: groupOfNames
objectClass: posixGroupAux
cn: libvirt
gidNumber: -1
member: uid=equinox,ou=users,dc=example,dc=org

Which combines with, on the client systems, in /etc/group:

libvirt:x:117:

to get equinox to be added to the existing (package manager created) libvirt group (which on some systems also has a different numeric gid), and have it applied on initgroups() as supplemental gid when logging in.

If there's some other way to do this, I've wasted a whole lot of work and some docs need updating 😆

[alexey-tikhonov]

man nsswitch.conf

merge       [SUCCESS=merge]  is  used  between two database entries.  When a group is located
in the first of the two group entries, processing will continue on to the next one.  If the group
is also found in the next entry (and the group name and GID are  an  exact  match), the member
list of the second entry will be added to the group object to be returned.

Do I understand correctly that the issue is floating GID?

[eqvinox]

Do I understand correctly that the issue is floating GID?

Indeed, essentially the gid value in LDAP is meaningless for this in most cases (might have edge cases if the system doesn't have the group); in the "absent" variant of my patch there is no gid at all, but other values do work for me.

[alexey-tikhonov]

Is your case similar to this - https://issues.redhat.com/browse/RHEL-109560 ?

[alexey-tikhonov]

That's definitely not a way to go.

There is sss_load_nss_symbols() helper in 'util/nss_dl_load.c' that can load 'libnss_files.so.2' to query local files.
But this would leave an open question about nss-altfiles, for example.

JFTR: I don't propose you to put more work into this atm. SSSD had "files provider" in the past (now removed), and idea of going back to messing with local NSS objects isn't too appealing...

[eqvinox]

Is your case similar to this - https://issues.redhat.com/browse/RHEL-109560 ?

Yes, pretty much exactly that. The description there is putting a lot of emphasis on the non-POSIX part of it; I don't care if it's "no gid" (= basically definition of non-POSIX) or some "placeholder gid" (like negative numbers).

[eqvinox]

+ FILE *etc_group = fopen("/etc/group", "r"); That's definitely *not* a way to go.

It's a perfectly fine thing for me to do in a patch to locally carry ;D. But yes I expected this feedback.

JFTR: I don't propose you to put more work into this atm. SSSD had "files provider" in the past (now removed), and idea going to messing with local NSS objects isn't too appealing...

I don't think this is really messing with local NSS objects, IMHO it's the LDAP group getting messed with... But yes, I assumed there might be "opinions about how to do this". This PR I did relatively little time across 2 days, something 'proper' might need a little more engineering. FWIW, this is a strong "vote" about the demand for RHEL-109560, someone (me) wanted it enough to write code for it ;).