RFE: Please consider supporting the systemd userdb varlink API for querying user/group records and membership

[sssd-bot]

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/4146

• Created at 2020-01-27 10:54:59 by lennart
• Assigned to nobody

---

The upcoming systemd version adds support for a concept called "userdb" which allows plugging in additional user/group database subsystems that provide rich user definitions in JSON objects. It's intended to be sufficiently simple and extensible for sssd/ldap to support.

Hookup is easy, and by doing this SSSD can supply systemd with various bits of per-user metadata information it will then use, in particular for configuring resource management (cgroups, …), security attributes and other runtime parameters. This for the first time would allow a provider like sssd to do per user resource management, enforced by systemd from its LDAP backend or so.

Documentation for the user/group records is here:

https://systemd.io/USER_RECORD
https://systemd.io/GROUP_RECORD

The API sssd would need to implement is this:

https://systemd.io/USER_GROUP_API

This is all petty new stuff and just got merged in systemd upstream. We hope to release this shortly in a new systemd version, and then introduce this to Fedora shortly after.

(I discussed this over the past months to three folks from (or close to) the sssd/ldap/samba community about this, including Alexander Bokovoy, Simo Sorce, Günther Deschner. Alexander suggested I should post an issue here about this, hence that's what I am doing. Alexander also indicated he'd like to see at least two more features added to the varlink API to make this really useful for sssd [which is username prefix searches + existence checks], but I guess that shouldn't stop us from starting the discussion here.)

Comments

---

Comment from thalman at 2020-03-13 14:47:29

Metadata Update from @thalman:

• Issue tagged with: Future milestone

[sabedevops]

Is work on this still planned for the future?

[pbrezina]

We currently don't have the capacity to work on this. But we would welcome external contributions.

[andreboscatto]

Dear Contributor/User,

Recognizing the importance of addressing enhancements, bugs, and issues for the SSSD project's quality and reliability, we also need to consider our long-term goals and resource constraints.

After thoughtful consideration, regrettably, we are unable to address this request at this time. To avoid any misconception, we're closing it; however, we encourage continued collaboration and contributions from anyone interested.

We apologize for any inconvenience and appreciate your understanding of our resource limitations. While you're welcome to open a new issue (or reopen this one), immediate attention may not be guaranteed due to competing priorities.

Thank you once again for sharing your feedback. We look forward to ongoing collaboration to deliver the best possible solutions, supporting in any way we can.

Best regards,
André Boscatto

[abbra]

Re-open. A comment from Lennart:

providing proper userdb records via the varlink interface will however have the effect that pam_systemd/logind and so on will understand whether the user they are dealing with is a regular user or not, because you can set the disposition field to any value you like.

The disposition part is important to allow systemd components to notice high-range IDs to be normal users (see systemd/systemd#30846 for some details)

[jaltman]

One concern I have is that the varlink interface for querying user/group records queries all configured data sources in parallel and requires that there be no UID/GID that is present in more than one of the data sources. This is true even if the data sources represent different subsets of metadata about a user. For example, there might be an entry that is sourced from a Kerberos realm | Active Directory domain and another which is sourced from an AuriStorFS|AFS Cell's Protection Service. In some environments an entity might exist in one or the other or both.

From the perspective of systemd's Container UID assignments the critical bit is whether or not a UID|GID is in use in any context.

[alexey-tikhonov]

@abbra, if SSSD will provide identity information both via classic NSS and via systemd userdb, there will be a collision with nss-systemd:

• IPA -> SSSD -> varlink userdb
• IPA -> SSSD -> NSS -> nss-systemd -> varlink userdb