|
The underlying premises upon which the rest is based are somewhat questionable, in my experience. I have a lot of dedicated user accounts for services, including dedicated user accounts for log services, far more than there are on any systemd system. My highest UID is 1468. I am a mere 2% of the distance to exhausting even the 16-bit ID space, let alone the full 32-bit ID space that the operating system actually has. And that 2% figure is without taking into account that on that particular machine these accounts have been assigned IDs starting from 1003. All of these are dealt with by the package installation/deinstallation mechanisms, and my experience is that those are what needs attention, with better, or at least widespread, mechanisms for handling dedicated user accounts as part of the installation/deinstallation process. The OpenBSD package manager provides a @newuser mechanism for this, which does all of the work of allocating and deallocating dedicated user accounts for services. On other package managers, the process is a more involved and explicitly written one, involving combinations of getent, pw, userdel, and useradd. These package managers would benefit from tools that enable the same sort of one-liners for this stuff that OpenBSD's package manager does. (I've written a library of shell functions for my packages.) Addressed this way, one still gets services running under the aegides of dedicated user accounts that only own and can modify little to no part of the filesystem, but with all of the allocation/deallocation and file/directory ownership work done once, statically, at installation/deinstallation time; rather than time and again dynamically at runtime. It's a parallel of the Do not parse configuration at runtime. principle. Do not do package management tasks, such as per-package user ID assignment and per-package directory creation/deletion, at runtime. |