]> git.ipfire.org Git - thirdparty/systemd.git/commitdiff
userdb: add support for looking up users or groups by uuid. (#37097)
authorLennart Poettering <lennart@poettering.net>
Wed, 8 Oct 2025 10:03:14 +0000 (12:03 +0200)
committerGitHub <noreply@github.com>
Wed, 8 Oct 2025 10:03:14 +0000 (12:03 +0200)
Followon to #37024.

This implements (mostly) what was suggested there, except that only a
single UUID is accepted (modifying things to support multiple is a
relatively straightforward change from here)

I'm not really convinced this is the right approach:

* I can't really think of any cases where you'd need to query by
multiple UUIDs (I guess you might want to lookup multiple users, but in
that case why aren't there "usernames" or "uids" arrays?)
* If I specify username "foo" and UID 1234 and UID 1234 exists and has
username "bar", I get back the error `ConflictingRecordFound`
* If I specify username "foo" and UUID abcdef... and username "foo"
exists but has UUID 123456..., I get back the error
`NonMatchingRecordFound`

This makes the two ID types behave differently.

Additionally, when querying by `uuid`, the multiplexer will always sends
`more: true`, which is fine but a little unexpected.

I do think unifying things through the `UserDBMatch` struct could make
sense, but in that case I think it would make sense to unify all query
types in that way (username, uid, uuid), identify when the filter is for
a single or multiple records, and centralise determination of conflict
vs non matching record errors.

`userdb_by_name`/`userdb_by_uid` could then become helper functions for
the simple case where no additional filtering is needed.

Thoughts?

One other thought: Should the multiplexer just pass through all
parameters, even unknown ones, to the backend services? Even if it
doesn't know how to filter by every property, the backends might, and it
would be useful to allow them to optimise things. (I realise the
disadvantage of this, ofc, is loss of error checking)

1  2 
src/userdb/userdbctl.c

Simple merge