userdb API: Support notifications about changes

[AdrianVovk]

Component

systemd-userdb

Is your feature request related to a problem? Please describe

Some services look up a user at some point in time and then use that information for a long time after. For example: logind looks up a user the first time they start any session, and then keeps that information unchanged for the entire lifetime of all of the user's sessions!

In situations like this, these services may end up with an out-of-date view about the user's settings or state.

Another use-case: imagine GNOME Settings starts talking to userdb to look up information about users, rather than AccountsService. How does GNOME Settings know that it needs to update its UI elements whenever the user record's display name, or profile picture, or etc change?

Describe the solution you'd like

Perhaps we need to introduce some mechanism to get notifications of changes in the userdb API. I see a couple of options:

1. A SubscribeUserUpdates() method that just sends notifications w/ a username whenever a user record changes. Could have a similar SubscribeGroupUpdates() method that does something similar for group records. Potential issues: how do we handle an interface changing with new methods that not all servers of that interface might support? If we implement it like this, maybe we send the whole updated user record to immediately be re-parsed by the client?

2. When calling GetUserRecord() for a single concrete user record, with more: true set, that subscribes the client to update notifications for that specific user. Potential issues: It's a change in behavior, might be unexpected. Also, it doesn't listen for all changes to all user records, so clients that wish to do so will need to open multiple connections

Describe alternatives you've considered

For my use-case, I need logind to monitor a user records for changes in their secure-lock status (as part of #31796). I could just add a special monitoring call to my internal io.systemd.SecureLockBackend service that tells logind specifically when a user is locked/unlocked. In the meanwhile, this is probably what I'll do.

But long-term, we should probably figure out what long-running clients should do about their user records.

The systemd version you checked that didn't have the feature you are asking for

256

[poettering]

So I guess adding this makes sense. But of course, being able to send out user change notifications is only possible on some backends, and we probably should advertise that somehow. Moreover, even on homed we can only send out modifications for some fields, not for others. (for example, for the current disk usage field we really shouldn't even attempt to send them out).

Hence idea: in the "status" section add a string array that lists all fields for which the backend will generate update events, to make this really clear to clients if they want to know. if the array is not set it means "we do not send out updates for this record, ever". This would then allow backends some freedom: if they want to send out notifications they can decide for which fields, and clients know when they need to fall back to some other means (time based polling?) or so.

I think a new method call for the actual subscription would make sense. Would call it SubscribeUserRecord() maybe. With the same signature as GetUserRecord() and insist that "more" is set.

Why separate from GetUserRecord()? because that call already makes use of "more" for a different purpose: underspecified requests result in userdb dumps after all, i.e return multiple records in a series. SubscribeUserRecord() otoh would return the same user record over and over, just in newer versions.

Clients should be able to simply call SusbcribeUserRecord() on any userdb service. If it fails with MethodNotFound they should handle this gracefully and would know the concept is not available.