On Thu, 2022-03-03 at 14:02 +0000, Adam Thorn via samba wrote:> On 03/03/2022 13:22, L. van Belle via samba wrote: > > And.. Small side note, this is different per distro. > > > > cat /etc/adduser.conf |grep UID > > > > # FIRST_SYSTEM_[GU]ID to LAST_SYSTEM_[GU]ID inclusive is the range > > for UIDs > > # package, may assume that UIDs less than 100 are unallocated. > > FIRST_SYSTEM_UID=100 > > LAST_SYSTEM_UID=999 > > > > # FIRST_[GU]ID to LAST_[GU]ID inclusive is the range of UIDs of > > dynamically > > FIRST_UID=1000 > > LAST_UID=29999 > > > > So, based on that, (*a Debian Buster server).. > > > > Try to avoid these system ranges or at least think about these.. > > One might also have systemd services that make use of "Dynamic > Users": > > https://0pointer.net/blog/dynamic-users-with-systemd.html > > systemd expects to be able to use UIDs in the range 61184?65519Why, that is a valid Unix ID range> and I > don't believe that's configurable.Why not ?> Whilst it's OK to use some UIDs in > that range because (quoting from the above link)... > > "You might wonder what happens if you already used UIDs from the > 61184?65519 range on your system for other purposes. systemd should > handle that mostly fine, as long as that usage is properly registered > in > the user database: when allocating a dynamic user we pick a UID, see > if > it is currently used somehow, and if yes pick a different one, until > we > find a free one. Whether a UID is used right now or not is checked > through NSS calls"And that is going to slow things down.> > ...if you were to assign most of that UID range to users which NSS > will > say are in use, it might cause problems for your systemd services.I have nothing personal against systemd, but only when it does what it was supposed to do, be a replacement for sysv init, it has just got out of hand now, thankfully most of the crap can be turned off. Please don't try to 'educate' me, I will not believe you. Rowland
On 03/03/2022 14:16, Rowland Penny via samba wrote:>> One might also have systemd services that make use of "Dynamic >> Users": >> >> https://0pointer.net/blog/dynamic-users-with-systemd.html >> >> systemd expects to be able to use UIDs in the range 61184?65519 > > Why, that is a valid Unix ID rangeI quote: "That's because distributions (specifically Fedora) tend to allocate regular users from below the 60000 range, and we don't want to step into that. ... Finally, we want to stay within the 16bit range">> and I >> don't believe that's configurable. > > Why not ?You'd have to ask the systemd authors! ("And before you ask: no this range cannot be changed right now, it's compiled in. We might change that eventually however." My meaning of "configurable" excludes "modify the source and recompile")>> Whilst it's OK to use some UIDs in >> that range because (quoting from the above link)... >> >> "You might wonder what happens if you already used UIDs from the >> 61184?65519 range on your system for other purposes. systemd should >> handle that mostly fine, as long as that usage is properly registered >> in >> the user database: when allocating a dynamic user we pick a UID, see >> if >> it is currently used somehow, and if yes pick a different one, until >> we >> find a free one. Whether a UID is used right now or not is checked >> through NSS calls" > > And that is going to slow things down.https://github.com/systemd/systemd/blob/main/src/core/dynamic-user.c#L179 looks like the relevant bit of code (based purely on a quick grep; I have zero familiarity with the code base). I was wrong: it'll try up to 100 UIDs in that range chosen mainly at random and then give up if they're all in use. I suspect that means that users with DynamicUser systemd services really should treat UIDs 61184-65519 as out-of-bounds if possible. A quick check on my Ubuntu Focal and Debian Bullseye servers finds almost no systemd services that use DynamicUsers, but the functionality is nonetheless there and others may have services installed that I do not! Adam