]> git.ipfire.org Git - thirdparty/systemd.git/commit
userdb: move filter of user/group records to the varlink server side (#36133)
authorLennart Poettering <lennart@poettering.net>
Wed, 29 Jan 2025 12:11:38 +0000 (13:11 +0100)
committerGitHub <noreply@github.com>
Wed, 29 Jan 2025 12:11:38 +0000 (13:11 +0100)
commit37cc66324c830f88020072ce869ef9775be80afc
tree551ce030d6e90496e80afee58e6c5679ca459e58
parent814e9eab1e403f2bda25e3fc34990c701578795c
parent35121184993fa7c9937a5c9654db3e64d5cb0815
userdb: move filter of user/group records to the varlink server side (#36133)

In v257 userdbctl gained support for filtering user records with fuzzy
matching and some other parameters. It was done on the client side only.
This PR adds server-side matching, by exendting the generic userdb
varlink api.

The api is generic any may have many other implementors, hence care is
taken to fallback to exclusively client side filtering in case the
service does not support the new parameters.

In fact I even opted to not actually implement server-side filtering in
any services but systemd-userdbd.service, because it's probably not too
much an optimization in relevant services (we might want to revisit this
later). By implementing it in userdbd the primary entrypoint for userdb
is however covered: the multiplexer interface which provides a single
interface for the multitude of backends. Or in other words: the
multiplexer itself supports server-side filtering even if its own
backends don't, and will hide this neatly away.

One nice side effect from not implementing server side filtering for all
our backends is that the fallback codepaths are comprehensively tested.

Note that this adds some unit tests but not new integration test for all
this, as the filtering tests for userdbctl already existed before, we
just move their implementation from the client to the server side.
TODO