From: Lennart Poettering Date: Wed, 8 Oct 2025 10:03:14 +0000 (+0200) Subject: userdb: add support for looking up users or groups by uuid. (#37097) X-Git-Tag: v259-rc1~363 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=9dcd4113d0966a8c7845bda8bc19a0045507963a;p=thirdparty%2Fsystemd.git 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) --- 9dcd4113d0966a8c7845bda8bc19a0045507963a