The package qqq.deb installs the program qqq that should run from uqqq user account. The package consist of the qqq program, qqq.conf config file and /etc/init.d/qqq initscript.

How should the package manage the creation of user uqqq? Are there any best practices or official guidelines about this?

  1. Just create the user automatically uqqq in postinst;
  2. Create the user automatically on first startup from /etc/init.d/qqq script;
  3. Create the user automatically on first startup of qqq program (without arguments)
  4. Don't create any user accounts, refuse to start unless the user is explicitly created by administrator (for example, using qqq --create-user);
  5. Don't create any user accounts, run unsafely from root by default;
  6. Interactively ask in postinst, init.d script or the qqq itself whether to create a user.

Should the package remove the user account when uninstalled?

  • 8
    The easiest way is to get to the answers of this question is to look at pre/post-installation scripts of official Debian packages. Just run grep adduser /var/lib/dpkg/info/*.postinst on any Debian based system to get many examples.
    – jofel
    Commented Oct 12, 2012 at 14:53
  • When adduser is used, it also needs to be depend on the package. See: lintian.debian.org/tags/…
    – Lekensteyn
    Commented Jul 30, 2014 at 15:27

3 Answers 3


The Debian wiki has some more comprehensive and specific guidance than the already-mentioned Debian Policy Manual. See AccountHandlingInMaintainerScripts:

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.

It should normally not be necessary to cross-check with getent whether an account already exists since adduser --system generally does the right thing. If not, please report a bug against adduser to keep your maintainer scripts simple.

The advice it provides on deleting accounts is inconclusive. However, I will note that the corresponding advice for fedora does not equivocate.

Do not remove users or groups We never remove users or groups created by packages. There's no sane way to check if files owned by those users/groups are left behind (and even if there would, what would we do with them?) and leaving those behind with ownerships pointing to now nonexistent users/groups may result in security issues when a semantically unrelated user/group is created later and reuses the UID/GID. Also, in some setups deleting the user/group might not be possible or/nor desirable (eg. when using a shared, remote user/group database). Cleanup of unused users/groups is left to the system administrators to take care of if they so desire.


As an administrator installing packages I'd expect my packages to automatically create the users they require in either pre or postinst, so that any files required to be owned by the user may be made so before the program is run.

Your program should only run as root if it needs to (eg bind to privileged port) and ideally should drop its privileges once it's finished doing what required root.

You can look at how other (installed) packages have handled this by using

grep -l adduser /var/lib/dpkg/info/*postinst /var/lib/dpkg/info/*preinst

and reading the files listed (most take more than one line of options).

Oddly enough, all but one of my installed packages that create a user use adduser to add users, but the adduser package is not a required package, so your package will have to be built to depend on it. The useradd program is used by the libuuid1 package, and is part of the passwd package which is a required package.

  • 2
    That's terrible, check the proper way of generating the preinst scripts rather than manually hacking one.
    – LtWorf
    Commented Aug 24, 2017 at 13:02
  • the --quiet approach seems very popular
    – vidstige
    Commented Oct 9, 2017 at 11:18
  • Package sssd-common package has a thorough example
    – bgStack15
    Commented Dec 10, 2020 at 15:29

Section 10.9. Permissions and owners in the Debian Policy Manual has what you are looking for (from "version, 2013-10-28"):

If you need to create a new user or group for your package there are two possibilities. Firstly, you may need to make some files in the binary package be owned by this user or group, or you may need to compile the user or group id (rather than just the name) into the binary (though this latter should be avoided if possible, as in this case you need a statically allocated id).

If you need a statically allocated id, you must ask for a user or group id from the base-passwd' maintainer, and must not release the package until you have been allocated one. Once you have been allocated one you must either make the package depend on a version of thebase-passwd' package with the id present in /etc/passwd' or /etc/group', or arrange for your package to create the user or group itself with the correct id (using adduser') in itspreinst' or postinst'. (Doing it in thepostinst' is to be preferred if it is possible, otherwise a pre-dependency will be needed on the `adduser' package.)

Note: The debian-devel list is quite active and answers such questions too (though that example is from 2003).

  • 6
    So, the short simplified answer is "Use adduser in postinst".
    – Vi.
    Commented Apr 11, 2014 at 1:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .