3832
Comment: editorial changes
|
4167
|
Deletions are marked like this. | Additions are marked like this. |
Line 60: | Line 60: |
=== Reasons for permitting both === My personal answer to this dilemma is to ... permit both: the local system administrator would decide whether he wants accounts to be purged automatically or not. This could be handled by a shell wrapper to deluser/delgroup (perhaps "policy-remove-user") and a simple conffile. -- LoicMinier |
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, it might be flawed, and its contents are under discussion at this time.
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
There are different opinions whether accounts should be deleted at all.
Reasons for not deleting accounts
It needs to be made sure uid/gid are not reused on the system, as there could be still log files or other stuff around and/or on the backup media. The easiest way to block uid/gid permanently is to leave the account in the password file.
If the account was "useable", make sure to set shell to /bin/false, to disable the password etc. [FIXME: What else?] when the package is purged.
Another advantage of not deleting accounts is that you don't have to hassle how to delete them.
Reasons for deleting accounts and how to do
Deleting an account is significantly harder than creating it 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. However, 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 account 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.
Another possibility is to fall back to userdel/groupdel if deluser is not found.
Debian policy should be made clearer with regard to what to do with an account on package removal.
Reasons for permitting both
My personal answer to this dilemma is to ... permit both: the local system administrator would decide whether he wants accounts to be purged automatically or not. This could be handled by a shell wrapper to deluser/delgroup (perhaps "policy-remove-user") and a simple conffile. -- ?LoicMinier