Andreas Henriksson <a.henriks...@gmail.com> writes: > ## common conventions
> users/groups should have an "invalid" prefix to avoid clashes with local > users > - sometimes inconvenient to change username and lots of packages doesn't > do this so should only be recommended when possible, not mandatory. > - Debian- (common, see eg. exim4), D (very rarely used?), and _ (also > used) are suggested prefix. I've always felt like this is the most critical question to resolve, probably because I previously worked at an institution with some 50,000 users and "permanent" assignment of usernames with turnover to the tune of 5,000 a year, which meant that there was a very substantial chance of conflict with any non-prefixed system user a Debian package might choose. Debian- has the advantage of clarity but the substantial disadvantage that it makes the name of the user long enough that a lot of common tools (ps, for instance) may show it as a UID instead of a name. I've not seen any strong argument against the _ prefix, and I think we should just standardize it (as a recommendation) for all new users and groups created by system packages. I'm not sure what to say about existing system users and groups. I kind of want to encourage people who picked an unprefixed name to rename that user or group with an appropriate tool, and I think that naming could usually be done safely (since the UID doesn't change, everything on the file system is still fine), but it could cause a few problems for some ways of managing site-local users that are aware of Debian user names. > previously created users should *not* (ever) be removed > - it's much less rare these days but still some packages removes > users/groups they created once the package is purged. > - the problem with removing users/groups (reusing uid/gid) is that files > on filesystem can be owned by them which could lead to possible > security issue. As Guillem mentioned, I as a Debian user and system administrator would dearly like to be able to configure Debian to delete created users when the package is purged. I understand the reasons why we don't think this is safe to do by default, but as an administrator, I care very, very strongly about the property that installing a package and then purging it should put the system back into the state it was in before the package was first installed. I strongly dislike packages that leave "junk" behind. I realize that the cost of this is that I cannot use system users for other purposes or give them ownership of files that aren't tracked by the package manager or maintainer scripts, and I'm quite okay with this tradeoff. I think Policy should say something like "created users and groups should not be removed by default, but may be removed on purge if the local administrator explicitly requests this, either for that package or as a system-wide default." > packages generally relies on adduser to do the work, which is basically > a wrapper to implement common debian conventions around useradd, but it > might not be policys place to explicitly require using a specific tool > like adduser. We can do the same dance that we do with debhelper, where we document the requirements and then clearly say that adduser is available as a tool that implements those requirements. (I'm fairly okay with just requiring packages use adduser, honestly, but I suspect someone has a reason why that's a bad idea.) > Packages commonly check if user/group already exists before calling > adduser to create them. Reason being quiet switch to adduser makes it > 'too quiet'. Might be better if adduser just gets fixed with eg. > implementing a '--exists-ok' argument, than documenting the current > convention in policy so should leave some room open for this. Yes, I think all the standard operations on users that we can anticipate should be simple invocations of adduser without any separate testing, error suppression, or other conditionals, and we should add whatever flags we need to add to adduser to make that work. (Packages may still have to test for whether adduser exists at all, of course, particularly in purge when dependencies may not be installed.) > Writing manual mantainerscript code should always be avoided, because > it's a common source of bugs. While I agree with you, this is generally outside the scope of Policy to talk about because Policy tries not to assume any particular packaging tools. Policy can usually only take a stance here if dpkg itself adds the functionality. But Lintian can certainly be opinionated about this. > There are also other issues like sharing the same namespace and now > being able to remove them. Thus adding users and group should be > avoided. Sometimes there are mechanisms that allow that which can be > used in more cases than is currently well known, so it might be good if > debian policy explicitly states that people should avoid adding > users/groups when possible. An example of a mechanism that allows not > creating static system users/groups is unit file option DynamicUser=yes > from systemd (and likely many others that I'm not aware of). We of course cannot assume that systemd is in use, and packages do need to correctly handle being run under other init systems. That raises an interesting question: should we allow packages to create users in their init script? That way, packages could provide an init script that creates a system user for some daemon to use, but a systemd unit that uses DynamicUser, if the only purpose of the user is simple privilege isolation. > if ! getent group "$NEWGROUP" >/dev/null; then > addgroup --force-badname \ > --system "$NEWGROUP" > fi As another minor point, we should not require --force-badname be used routinely. When we pick a prefix, we should add a --package flag (possibly with some other name) to adduser that *requires* the name start with whatever chosen prefix we use and, of course, doesn't complain that's a bad name. Or maybe even just make --system be that flag, although that's not backward-compatible with packages that use other prefixes. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
