In practice, Debian and Ubuntu have fixed minimum system UIDs and GIDs | Hacker News Reader

In practice, Debian and Ubuntu have fixed minimum system UIDs and GIDs

utcc.utoronto.ca

40 pointszdw21 comments

When creating users, I always manually pick a UID/GID, generally starting at 2000, which, from experience, is the lowest number that does not conflict with any system range on any UNIX-like OS.

Why do you manually pick user UID/GIDs?

So they are the same everywhere.

Cool, just curious...why do you want them to be the same everywhere?

NFS?

Or any way of moving files around that doesn't translate UIDs or where translating UIDs is more work; ex. rsync will default to trying to match by user name, but I'm pretty sure tar won't always

NFS, and also just sneakernet. It means you don't have to worry about formatting large external disks with something weird like exFAT.

I start my manual picks at 3000 to avoid conflicts with users created by people like you. (I'm not only making a joke, I really do. My siblings are people like you, too.)

I appreciate your anti-collision efforts. ;)

Is this a problem? What am I missing?

It's saying if you set a programmatic minimum, (in adduser.conf), that you'll get errors whenever you try an upgrade in Debian or Ubuntu, so setting a programmatic minimum isn't practically possible.

So FIRST_SYSTEM_UID and LAST_SYSTEM_UID aren't usable parameters.

I think the question is whether this is a problem in practice. Why would you want to raise FIRST_SYSTEM_UID?

From the article "so that you can (for example) alter them to avoid a range of low UIDs or GIDs that your environment has for historical reasons".

Ah, I missed that. Thanks for pointing it out!

Isn’t the situation of preserving local file modifications covered in the Debian handbook[0]? You simply drop a config for apt to not overwrite files you’ve changed…

  /etc/apt/apt.conf.d/local

  DPkg::options { "--force-confdef"; "--force-confold"; }

[0] https://debian-handbook.info/browse/wheezy/sect.package-meta...

users != conf files.

The problem is that during first install you can't configure the system user id range, so they'll start at 100. Later you decide to increase that to 150 for whatever reason. Even later, an apt-get upgrade upgrades a system package that owns a user in the 100-149 range. The upgrades process includes setting up the user again. User setup sees that the user exists but isn't in the system user range, this is presumably interpreted as a security risk and so fails the upgrade.

As a result the minimum system user uid is in practice not able to be increased without breaking upgrades.

systemD considerations for UID/GIDs:

* https://systemd.io/UIDS-GIDS/

This is an example of why I largely stopped tweaking files in /etc and other system settings. I used to geek out over "tuning" and "optimizing" and "hardening" stuff but it ends up creating obscure problems. It shouldn't, but it often does.

In this case it is included hardening/sanity checks that is creating these "problems". If you change something that triggers them to "harden" your system, you're probably doing the opposite of what you intended.

> Unfortunately, in practice the start of the range for both system UIDs and GIDs is fixed.

Not a bug, but a security feature. You don't want an unbounded amount of privileged users. And certainly don't need it.

Same for ports, string lengths, array lengths, ...

The real problems are well-known dpkg quirks on updates.

Reply on news.ycombinator.com