Bug#228692: User/group creation/removal in package maintainer scripts

[Russ Allbery <rra@debian.org>]

Andreas Henriksson <a.henriksson@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 (rra@debian.org)               <http://www.eyrie.org/~eagle/>