HN Explorer

21 comments

[ 3.2 ms ] story [ 59.2 ms ] thread
rbranson
Is this a problem? What am I missing?
tyingq
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.

Sebb767
I think the question is whether this is a problem in practice. Why would you want to raise FIRST_SYSTEM_UID?
nieve
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".
Sebb767
Ah, I missed that. Thanks for pointing it out!
LeoPanthera
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.
whitepoplar
Why do you manually pick user UID/GIDs?
LeoPanthera
So they are the same everywhere.
whitepoplar
Cool, just curious...why do you want them to be the same everywhere?
mzs
NFS?
yjftsjthsd-h
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
LeoPanthera
NFS, and also just sneakernet. It means you don't have to worry about formatting large external disks with something weird like exFAT.
mboerwink
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.)
LeoPanthera
I appreciate your anti-collision efforts. ;)
visualphoenix
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...
andreareina
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.

throwawayboise
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.
chmod775
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.
rurban
> 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.