Differences between revisions 6 and 7
Revision 6 as of 2006-09-29 12:15:15
Size: 3832
Editor: ZugSchlus
Comment: editorial changes
Revision 7 as of 2006-09-29 13:06:54
Size: 4167
Editor: ?LoicMinier
Comment:
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