[arch-dev-public] cleaning up the gid/uid mess

[Daniel Micay]

The current strategy for handling this involves reserving ids for every
package needing users / groups and tracking it on the wiki. The wiki
doesn't actually correspond well to the state of packages in the
repositories, as it's missing quite a few users / groups and has plenty
that are not used by any official package.

I wanted to start moving away some more services from root, but I think
this needs to be dealt with first.

I suggest reserving a large range (500-999) for *dynamic* ids, and then
moving packages to groupadd -r / useradd -r *without* a hard-wired id
whenever possible. Most packages can easily get away with this, because
the configuration files only reference it by name and they don't have
any packaged files that need to be in the group.

An example of a package already using a dynamic id is `git`, but it's
very precarious right now because it relies on an unstated assumption
that no one is going to reserve high static ids.

Luckily, the highest id recorded as reserved in the 0-999 system range
is 492, and most of the ids in the lower half are still free. We could
make the static range smaller by editing some ids after purging most of
them.

Debian only has 100 ids reserved for static usage in packages (0-99)
with 900 for dynamic ids (100-999).

https://www.debian.org/doc/debian-policy/ch-opersys.html

Fedora does a 200 / 800 split instead:

https://fedoraproject.org/wiki/Features/1000SystemAccounts

Regardless of what we decide to do, I think we need *something* written
down as the official policy rather than just continuing to hope it works
out.

One thing to note is that using dynamic ids makes leaving unpackaged
files behind (/var/lib/foobar) dangerous if the user/group is deleted
since another package will get the id. Fedora deals with this by *never*
deleting users/groups... and that led to systemd making the same choice
in the sysusers handling. The `userdel` command can be passed -r to wipe
out the home directory, which may not be enough to get all the files and
may not be sane.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-dev-public/attachments/20140809/f6af780b/attachment.asc>