]> git.ipfire.org Git - thirdparty/systemd.git/commit
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)
commit9dcd4113d0966a8c7845bda8bc19a0045507963a
treee20502f5e04b6e2eb7b85954bb665143c96deeca
parented1c2d1541c839c73e2158a2198fc109719604b5
parent466562c69b75cec197176f556b940a43bb8350f2
userdb: add support for looking up users or groups by uuid. (#37097)

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)
src/userdb/userdbctl.c