Account Handling in Maintainer Scripts
This script is an attempt to build a list of things to do with Unix system accounts in Debian Maintainer scripts. This is not an official document, and it might be flawed.
Introduction
Some packages need their own system account to properly function. These things are most probably due to security considerations, since it should be avoided to have unrelated processes running under the same UID (allowing them to attack each other, for example using ptrace type attacks), and it is desireable to have tight control on file access rights.
Account Naming
Naming of system accounts is a highly discussed matter. Accounts created by packages should be unlikely to collide with locally created users. One of the most popular methods to ensure this is starting the account name with an underscore or a Capital. Some packages have decided to make a collision extra unlikely, choosing an account name like Debian-packagename. This is, however, highly discussed.
A collision free way to name system accounts should really be mentioned in Debian policy to stop this uncontrolled growth of different methods.
Account creation
The adduser program does the right thing if called with the --system option. It is thus usually only necessary to call
adduser --system $USERNAME
in your postinst to create the account with logins disabled, a primary group of nogroup and a home directory under /home. If you want other options, add them as you want to.
Account deletion
Deleing an account is significantly harder because of the following reasons:
- at package purge time, a package cannot rely any more on its dependencies being installed
- the local admin might have decided to chown unrelated files to the package account
- if we remove the account on purge, it is possible that the UID will be re-used at some later time
Because of this reasoning, it is highly discussed whether a package should even try removing its account on uninstall or purge. There are also voices saying that a package should try to vanish without a trace, and that naturally includes the account.
Since you cannot rely on adduser being present at package purge time, you can remove the accoutn at package uninstall time if you're positive that none of your config files, logs and other files that are only removed on purge belong to your account. Otherwise, it is acceptable to mask the deluser call in the purge code with
if [ -x "$(command -v deluser)" ]; then deluser ... else echo >&2 "not removing system account because deluser executeable was not found" fi
which will result in a warning, purge completing and leaving the account around if adduser was removed after the package was uninstalled and before it was purged.