the discussion on handling of system users on package removal became silent
again, let me try to summarize ...:
* To avoid reusing uids, system users created by packages should not be
removed by the package. There may be still files owned by that user (think
also about removable media, backups, ...) that a different user (with
recycled uid) should not get access to. Of course the sysadmin may manually
remove such obsolete users and groups.
* A 'lockuser' tool should be added to the adduser package to properly disable
an unused system account, to be called from postrm remove. adduser needs to
properly unlock a previously locked account.
... and revive the discussion with some new points:
Concerning removing the home directory ... I think there are three groups of
1) the home directory itself
2) files created by running the daemon
(or whatever the package was supposed to do)
3) files created by the sysadmin by doing something like
su - $pkgsysuser
in order to debug things, ...
I don't think maintainer scripts should care for group 3 files as they don't
result from proper operation of the package (and will cause group 1 to be
left over). These files could be covered by
rm -rf $(getent passwd $pkgsysuser | cut -d: -f6)/
which could be harmful if the sysadmin modified $pkgsysuser.
rm -rf /var/lib/$pkgsysuser/
could be problematic as well.
Group 2 (probably state files) should be taken care of by postrm purge.
For the homedirectory itself (usually /var/lib/$whatever) I would suggest to
ship this as an empty directory in the package, and let the postinst script
set proper ownership and permissions after creating the user.
That way dpkg should take care and remove it if it's empty. I don't think
leaving a (locked) system user with a nonexisting home is a problem.
There may be problems if the user/homedir already exists. These need to be
addressed by adduser or the maintainer script. Following is a list I could
think of, but I didn't check the behavior of adduser in these cases:
The user exists
* but is not a system user
* but remotely (nis, ldap, ...) and modification may not be possible
* but the group is different
* but the gecos is different
* but the homedir is different
* but the shell is different
The homedirectory exists
* but is a file
* but is owned by someone else
* but has weird permissions (including 777, 000)
* but is a symbolic link (+ combine with above cases)
The homedirectory cannot be created.
Potentially different handling of these discrepancies is needed during new
installations and upgrades.
I still think that using dpkg-maintscript-helper may be helpful for adding
system users. A system_user sub-command that would take arguments like
adduser (and might add some defaults if not specified, e.g. gecos). Some
possible extensions could be --home-owner, --home-group, --home-permissions.
A proper dependency on adduser should be added to the misc:Depends substvar
(at least if debhelper is used, e.g. via debian/package.maintscript)
In postinst configure this would produce in an adduser call (with some
In postrm remove this would produce a lockuser call (or could even implement a
lockuser equivalent) and in postrm purge (and remove?) it should try a rmdir
on the homedir of the system user (unless --no-create-home is given). If this
fails (and the directory still exists), a diagnostic should be emitted (only
in purge because any state files etc. in the homedir are expected to be
removed by the postrm purge first).
Concerning piuparts, we should probably have an install-purge-install test for
packages that create system users and also an install-purge-mangle-install
test that mangles the passwd entries of added system users before the package
gets installed a second time.