Differences between revisions 4 and 5
Revision 4 as of 2006-09-29 11:26:27
Size: 3493
Editor: ?aba
Comment:
Revision 5 as of 2006-09-29 11:29:54
Size: 3493
Editor: NicoGolde
Comment:
Deletions are marked like this. Additions are marked like this.
Line 45: Line 45:
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 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

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

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. As the only way to block uid/gid permanently is to leave values in the password file.

If the account was "useable", but sure to set shell to /bin/false etc. [FIXME: What else?]

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 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 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.