Bug#621833: System user handling in packages: status of discussion

[Andreas Beckmann <debian@abeckmann.de>]

Hi all,

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 
files:
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 
chown/chmod following).
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.

Andreas