+<item>The software runs with the minimum privileges it needs:
+
+<list>
+<item>The package does install binaries setuid or setgid.
+<prgn>Lintian</prgn> will warn of <url id="
+http://lintian.debian.org/reports/Tsetuid-binary.html" name="setuid">,
+<url id="http://lintian.debian.org/reports/Tsetgid-binary.html"
+name="setgid"> and <url
+id="http://lintian.debian.org/reports/Tsetuid-gid-binary.html"
+name="setuid and setgid"> binaries.
+
+<item>The daemons the package provide run with a
+low privilege user (see <ref id="bpp-lower-privs">)
+
+</list>
+
+<item>Programmed (i.e., <prgn>cron</prgn>) tasks running in the
+system do NOT run as root or, if they do, do not implement complex
+tasks.
+
+</list>
+
+<p>If you have to do any of the above make sure the programs that
+might run with higher privileges have been audited for security
+bugs. If you are unsure, or need help, contact the <url
+id="http://www.debian.org/security/audit/" name="Debian Security Audit
+team">. In the case of setuid/setgid binaries, follow the Debian
+policy section regarding
+<url id="http://www.debian.org/doc/debian-policy/ch-files.html#s10.9"
+name="permissions and owners">
+</p>
+
+<p>For more information, specific to secure programming, make sure you
+read (or point your upstream to) <url
+id="http://www.dwheeler.com/secure-programs/" name="Secure Programming
+for Linux and Unix HOWTO"> and the <url
+id="https://buildsecurityin.us-cert.gov/portal/" name="Build Security
+In"> portal. For more information specific to Debian security you can
+read the <url
+id="http://www.debian.org/doc/manuals/securing-debian-howto/"
+name="Debian Security Manual">
+</p>
+
+<!-- This should be explained here until #291177 gets fixed and this is
+ added to poliy -->
+
+ <sect1 id="bpp-lower-privs">
+ <heading>System users and groups for software daemons
+
+<p>If your software runs a daemon that does not need root privileges,
+you need to create a user for it. There are two kind of Debian users
+that can be used by packages: static uids (assigned by
+<package>base-passwd</package>) and dynamic uids in the range assigned
+to system users.
+
+<p>In the first case, you need to ask for a user or group id to the
+<package>base-passwd</package>, and a proper versioned depends to the
+<package>base-passwd</package> package that provides the user.
+
+<p>In the second case, you need to create the system user either in
+the <em>preinst</em> or in the <em>postinst</em> and make the package
+depend on <tt>adduser (>= 3.11)</tt>.
+
+<p>Running programs with a user with limited privileges makes sure
+that any security issue with the program makes limited damaged to the
+system and follows the principle of <em>least privilege</em> you can
+limit privileges in programs through other mechanisms besides running
+as non-root. Fore more information, read the <url
+id="http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/minimize-privileges.html"
+name="Minimize Privileges"> chapter of the <em>Secure Programming for
+Linux and Unix HOWTO</em> book.
+
+ <sect2 id="bpp-create-sysuser">
+ <heading>Creating system users and groups
+
+<p>The following example code creates the user and group the daemon
+will run as when the package is installed or upgraded:
+
+<example>
+[...]
+case "$1" in
+ install|upgrade)
+
+ # If the package has default file it could be sourced, so that
+ # the local admin can overwrite the defaults
+ # Notice that the package could handle this defaults through
+ # debconf so that the local admin could select a different
+ # user name for the system user than the one hardcoded in the
+ # package
+
+ [ -f "/etc/default/<var>packagename</var>" ] && . /etc/default/<var>packagename</var>
+
+
+ # Sane defaults:
+
+ [ -z "$SERVER_HOME" ] && SERVER_HOME=<var>server_dir</var>
+ [ -z "$SERVER_USER" ] && SERVER_USER=<var>server_user</var>
+ [ -z "$SERVER_NAME" ] && SERVER_NAME="<var>Server description</var>"
+ [ -z "$SERVER_GROUP" ] && SERVER_GROUP=<var>server_group</var>
+
+ # Groups that the user will be added to, if undefined, then none.
+ # Some daemons might need additional privileges and those can be
+ # granted by adding it to additional groups.
+ ADDGROUP=""
+
+
+ # create user to avoid running server as root
+ # 1. create group if not existing
+ if ! getent group | grep -q "^$SERVER_GROUP:" ; then
+ echo -n "Adding group $SERVER_GROUP.."
+ addgroup --quiet --system $SERVER_GROUP 2>/dev/null ||true
+ echo "..done"
+ fi
+ # 2. create homedir if it does not exist
+ test -d $SERVER_HOME || mkdir $SERVER_HOME
+ # 3. create user if it does not exist
+ if ! getent passwd | grep -q "^$SERVER_USER:"; then
+ echo -n "Adding system user $SERVER_USER.."
+ adduser --quiet \
+ --system \
+ --ingroup $SERVER_GROUP \
+ --no-create-home \
+ --disabled-password \
+ $SERVER_USER 2>/dev/null || true
+ echo "..done"
+ # 4. adjust passwd entry, only do this if the package
+ # creates the user
+ usermod -c "$SERVER_NAME" \
+ -d $SERVER_HOME \
+ -g $SERVER_GROUP \
+ $SERVER_USER
+ else
+ # The package might want to check if the user already exists
+ # and it is *not* a system user, in this case it should abort
+ # the installation (like in this example) or ask the administrator
+ # since otherwrise it might have unexpected consequences.
+ # Some packages try to prevent collision by using a prefix such as 'Debian-'
+ for LINE in `grep SYSTEM_UID /etc/adduser.conf | grep -v "^#"`; do
+ case $LINE in
+ FIRST_SYSTEM_UID*)
+ FIST_SYSTEM_UID=`echo $LINE | cut -f2 -d '='`
+ ;;
+ LAST_SYSTEM_UID*)
+ LAST_SYSTEM_UID=`echo $LINE | cut -f2 -d '='`
+ ;;
+ *)
+ ;;
+ esac
+ done
+ # Abort package installation if the user has not been created by
+ # us.
+ if [ -n "$FIST_SYSTEM_UID" ] && [ -n "$LAST_SYSTEM_UID" ]; then
+ if USERID=`getent passwd $SERVER_USER | cut -f 3 -d ':'`; then
+ if [ -n "$USERID" ]; then
+ if [ "$FIST_SYSTEM_UID" -le "$USERID" ] && \
+ [ "$USERID" -le "$LAST_SYSTEM_UID" ]; then
+ echo "The user $SERVER_USER already exists as a non system user!" >&2
+ echo "Aborting package installation" >&2
+ exit 1
+ fi
+ fi
+ fi
+ fi
+ fi
+
+ # 5. adjust file and directory permissions
+ # The example below sets the server home as 750 as it
+ # contains (hypothetically) sensible information.
+ if ! dpkg-statoverride --list $SERVER_HOME >/dev/null
+ then
+ chown -R $SERVER_USER:adm $SERVER_HOME
+ chmod u=rwx,g=rxs,o= $SERVER_HOME
+ fi
+ # 6. Add the user to the ADDGROUP group
+ if test -n $ADDGROUP
+ then
+ if ! groups $SERVER_USER | grep -q $ADDGROUP; then
+ adduser $SERVER_USER $ADDGROUP
+ fi
+ fi
+ ;;
+ configure)
+
+[...]
+</example>
+
+ <sect2 id="bpp-using-sysuser">
+ <heading>Using system users
+
+<p>In order to make use of the system user you have to make sure that the
+init.d script file:
+
+<list>
+<item>Starts the daemon dropping privileges, if the software does not
+do the <manref name="setuid" section="2"> or <manref name="seteuid"
+section="2"> call itself, you can use the <tt>--chuid</tt>
+call of <prgn>start-stop-daemon</prgn>.
+
+<item>Stops the daemon only if the user id matches, you can use the
+<prgn>start-stop-daemon</prgn> <tt>--user</tt> option
+for this.
+
+<item>Does not run if either the user or the group do not exist:
+<example>
+ if getent passwd | grep -q "^<var>server_user</var>:"; then
+ echo "Server user does not exist. Aborting" >&2
+ exit 1
+ fi
+ if getent group | grep -q "^<var>server_group</var>:" ; then
+ echo "Server group does not exist. Aborting" >&2
+ exit 1
+ fi
+</example>
+
+</list>
+
+<!-- TODO: write about ownership of files:
+ * configuration files: readable but not owned
+ * logfiles, writable, but not once rotated
+-->
+
+ <sect2 id="bpp-removing-sysuser">
+ <heading>Removing system users
+
+<p>If the package creates the system user it can remove it when it is
+purged in its <em>postrm</em>, this currently <em>not</em> recommended
+since it has a few known
+<footnote>
+Some relevant threads discussing these issues include:
+<url
+id="http://lists.debian.org/debian-mentors/2004/10/msg00338.html">,
+<url id="http://lists.debian.org/debian-devel/2004/05/msg01156.html">
+and
+<url id="http://lists.debian.org/debian-devel/2005/10/msg00988.html">.
+</footnote>
+drawbacks. For example, files created by the daemon (or by an admin
+impersonating it) either on the local filesystem or in backup files will be
+orphaned and might be taken over by a new system user in the future if it is
+assigned the same uid. On the other hand, an unused local system user can be
+used to access even if the account has been locked (as some authentication
+systems might not use PAM or shadow authentication).
+
+<p>If you want to remove a system user and there is a possibility of it
+leaving orphaned files, the administrator should be asked for the preferred
+action either when the package is installed or when it is removed (see <ref
+id="debconf">).
+
+<p>The following example code removes the user and groups created
+before only, and only if, the uid is in the range of dynamic assigned system
+uids and the gid is belongs to a system group:
+
+<example>
+case "$1" in
+ purge)
+[...]
+ # find first and last SYSTEM_UID numbers
+ for LINE in `grep SYSTEM_UID /etc/adduser.conf | grep -v "^#"`; do
+ case $LINE in
+ FIRST_SYSTEM_UID*)
+ FIST_SYSTEM_UID=`echo $LINE | cut -f2 -d '='`
+ ;;
+ LAST_SYSTEM_UID*)
+ LAST_SYSTEM_UID=`echo $LINE | cut -f2 -d '='`
+ ;;
+ *)
+ ;;
+ esac
+ done
+ # Remove system account if necessary
+ CREATEDUSER="<var>server_user</var>"
+ if [ -n "$FIST_SYSTEM_UID" ] && [ -n "$LAST_SYSTEM_UID" ]; then
+ if USERID=`getent passwd $CREATEDUSER | cut -f 3 -d ':'`; then
+ if [ -n "$USERID" ]; then
+ if [ "$FIST_SYSTEM_UID" -le "$USERID" ] && \
+ [ "$USERID" -le "$LAST_SYSTEM_UID" ]; then
+ echo -n "Removing $CREATEDUSER system user.."
+ deluser --quiet $CREATEDUSER || true
+ echo "..done"
+ fi
+ fi
+ fi
+ fi
+ # Remove system group if necessary
+ CREATEDGROUP=<var>server_group</var>
+ FIRST_USER_GID=`grep ^USERS_GID /etc/adduser.conf | cut -f2 -d '='`
+ if [ -n "$FIST_USER_GID" ] then
+ if GROUPGID=`getent group $CREATEDGROUP | cut -f 3 -d ':'`; then
+ if [ -n "$GROUPGID" ]; then
+ if [ "$FIST_USER_GID" -gt "$GROUPGID" ]; then
+ echo -n "Removing $CREATEDGROUP group.."
+ delgroup --only-if-empty $CREATEDGROUP || true
+ echo "..done"
+ fi
+ fi
+ fi
+ fi
+[...]
+</example>
+
+<p>Other possibilities, are to make sure the account is locked (has an invalid
+password and <em>/bin/false</em> as a shell) and modify the GECOS field
+pointing out that the account is no longer used.
+
+</sect1>
+
+</sect>
+
+ <sect id="bpp-config-mgmt">
+ <heading>Configuration management with <package>debconf</package></heading>
+ <p>
+<package>Debconf</package> is a configuration management system which
+can be used by all the various packaging scripts
+(<file>postinst</file> mainly) to request feedback from the user
+concerning how to configure the package. Direct user interactions must
+now be avoided in favor of <package>debconf</package>
+interaction. This will enable non-interactive installations in the
+future.
+ <p>
+Debconf is a great tool but it is often poorly used. Many common mistakes
+are listed in the <manref name="debconf-devel" section="7"> man page.
+It is something that you must read if you decide to use debconf.
+Also, we document some best practices here.
+ <p>
+These guidelines include some writing style and typography
+recommendations, general considerations about debconf usage as well as
+more specific recommendations for some parts of the distribution (for
+instance, the installation system).
+
+ <sect1>Do not abuse debconf
+ <p>
+Since debconf appeared in Debian, it has been widely abused and
+several criticisms received by the Debian distribution come from
+debconf abuse with the need of answering a wide bunch of questions
+before getting any little thing installed.
+ <p>
+Keep usage notes to what they belong: the NEWS.Debian, or
+README.Debian file. Only use notes for important notes which may
+directly affect the package usability. Remember that notes will always
+block the install until confirmed or bother the user by email.
+ <p>
+Carefully choose the questions priorities in maintainer scripts. See
+<manref name="debconf-devel" section="7"> for details about priorities.
+Most questions should use medium and low priorities.
+
+ <sect1>General recommendations for authors and translators
+ <p>
+ <sect2>Write correct English
+ <p>
+Most Debian package maintainers are not native English speakers. So,
+writing properly phrased templates may not be easy for them.
+ <p>
+Please use (and abuse) &email-debian-l10n-english; mailing
+list. Have your templates proofread.
+ <p>
+Badly written templates give a poor image of your package, of your
+work...or even of Debian itself.
+ <p>
+Avoid technical jargon as much as possible. If some terms sound common
+to you, they may be impossible to understand for others. If you cannot
+avoid them, try to explain them (use the extended description). When
+doing so, try to balance between verbosity and simplicity.
+
+ <sect2>Be kind to translators
+ <p>
+Debconf templates may be translated. Debconf, along with its sister
+package <prgn>po-debconf</prgn> offers a simple framework for getting
+templates translated by translation teams or even individuals.
+ <p>
+Please use gettext-based templates. Install <package>po-debconf</package> on your
+development system and read its documentation ("man po-debconf" is a
+good start).
+ <p>
+Avoid changing templates too often. Changing templates text induces
+more work to translators which will get their translation "fuzzied". If
+you plan changes to your original templates, please contact
+translators. Most active translators are very reactive and getting
+their work included along with your modified templates will save you
+additional uploads. If you use gettext-based templates, the
+translator's name and e-mail addresses are mentioned in the po files
+headers.
+ <p>
+The use of the <prgn>podebconf-report-po</prgn> from the
+po-debconf package is highly recommended to warn translators which
+have incomplete translations and request them for updates.
+ <p>
+If in doubt, you may also contact the translation team for a given
+language (debian-l10n-xxxxx@lists.debian.org), or the
+&email-debian-i18n; mailing list.
+ <p>
+Calls for translations posted to
+&email-debian-i18n; with the <file>debian/po/templates.pot</file> file
+attached or referenced in a URL are encouraged. Be sure to mentions in
+these calls for new translations which languages you have existing
+translations for, in order to avoid duplicate work.
+ <sect2>Unfuzzy complete translations when correcting typos and spelling
+ <p>
+
+When the text of a debconf template is corrected and you are
+<strong>sure</strong> that the change does <strong>not</strong> affect
+translations, please be kind to translators and unfuzzy their
+translations.
+ <p>
+If you don't do so, the whole template will not be translated as long
+as a translator will send you an update.
+ <p>
+To <strong>unfuzzy</strong> translations, you can proceed the following way:
+ <enumlist>
+ <item>
+Put all incomplete PO files out of the way. You can check the
+completeness by using (needs the <package>gettext</package> package installed):
+<example>for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null
+--statistics $i; done</example>
+ <item>
+move all files which report either fuzzy strings to a temporary
+place. Files which report no fuzzy strings (only translated and
+untranslated) will be kept in place.
+ <item>
+now <strong>and now only</strong>, modify the template for the typos
+and check again that translation are not impacted (typos, spelling
+errors, sometimes typographical corrections are usually OK)
+ <item>
+run <prgn>debconf-updatepo</prgn>. This will fuzzy all strings
+you modified in translations. You can see this by running the above
+again
+ <item>
+use the following command:
+<example>for i in debian/po/*po; do msgattrib --output-file=$i --clear-fuzzy $i; done</example>
+ <item>
+move back to debian/po the files which showed fuzzy strings in the first step
+ <item>
+run <prgn>debconf-updatepo</prgn> again
+ </enumlist>
+ <sect2>Do not make assumptions about interfaces
+ <p>
+Templates text should not make reference to widgets belonging to some
+debconf interfaces. Sentences like "If you answer Yes..." have no
+meaning for users of graphical interfaces which use checkboxes for
+boolean questions.
+ <p>
+String templates should also avoid mentioning the default values in
+their description. First, because this is redundant with the values
+seen by the users. Also, because these default values may be different
+from the maintainer choices (for instance, when the debconf database
+was preseeded).
+ <p>
+More generally speaking, try to avoid referring to user actions.
+Just give facts.
+
+ <sect2>Do not use first person
+ <p>
+You should avoid the use of first person ("I will do this..." or "We
+recommend..."). The computer is not a person and the Debconf templates
+do not speak for the Debian developers. You should use neutral
+construction and often the passive form. Those of you who already
+wrote scientific publications, just write your templates like you
+would write a scientific paper.
+
+ <sect2>Be gender neutral
+ <p>
+The world is made of men and women. Please use gender-neutral
+constructions in your writing. This is not Political Correctness, this
+is showing respect to all humanity.
+
+
+ <sect1>Templates fields definition
+ <p>
+This part gives some information which is mostly taken from the
+<manref name="debconf-devel" section="7"> manual page.
+
+ <sect2>Type
+ <p>
+
+ <sect3>string:
+ <p>
+Results in a free-form input field that the user can type any string into.
+
+ <sect3>password:
+ <p>
+Prompts the user for a password. Use this with caution; be aware that
+the password the user enters will be written to debconf's
+database. You should probably clean that value out of the database as
+soon as is possible.
+
+ <sect3>boolean:
+ <p>
+A true/false choice. Remember: true/false, NOT YES/NO...
+
+ <sect3>select:
+ <p>
+A choice between one of a number of values. The choices must be
+specified in a field named 'Choices'. Separate the possible values
+with commas and spaces, like this: Choices: yes, no, maybe
+
+ <sect3>multiselect:
+ <p>
+Like the select data type, except the user can choose any number of
+
+ items from the choices list (or chose none of them).
+
+ <sect3>note:
+ <p>
+Rather than being a question per se, this datatype indicates a note
+that can be displayed to the user. It should be used only for
+important notes that the user really should see, since debconf will go
+to great pains to make sure the user sees it; halting the install for
+them to press a key, and even mailing the note to them in some
+cases.
+
+ <sect3>text:
+ <p>
+This type is now considered obsolete: don't use it.
+
+ <sect3>error:
+ <p>
+<strong>THIS TEMPLATE TYPE IS NOT HANDLED BY DEBCONF YET.</strong>
+ <p>
+It has been added to cdebconf, the C version of debconf, first used in
+the Debian Installer.
+ <p>
+Please do not use it unless debconf supports it.
+ <p>
+This type is designed to handle error message. It is mostly similar to
+the "note" type. Frontends may present it differently (for instance,
+the dialog frontend of cdebconf draws a red screen instead of the
+usual blue one).
+
+
+ <sect2>Description: short and extended description
+ <p>
+Templates descriptions have two parts: short and extended. The short
+description is in the "Description:" line of the template.
+ <p>
+The short description should be kept short (50 characters or so) so
+that it may be accomodated by most debconf interfaces. Keeping it
+short also helps translators, as usually translations tend to end up
+being longer than the original.
+ <p>
+The short description should be able to stand on its own. Some
+interfaces do not show the long description by default, or only if the
+user explicitely asks for it or even do not show it at all. Avoid
+things like "What do you want to do?"
+ <p>
+The short description does not necessarily have to be a full
+sentence. This is part of the "keep it short and efficient"
+recommendation.
+ <p>
+The extended description should not repeat the short description word
+for word. If you can't think up a long description, then first, think
+some more. Post to debian-devel. Ask for help. Take a writing class!
+That extended description is important. If after all that you still
+can't come up with anything, leave it blank.
+ <p>
+The extended description should use complete sentences. Paragraphs
+should be kept short for improved readability. Do not mix two ideas
+in the same paragraph but rather use another paragraph.
+ <p>
+Don't be too verbose. Some debconf interfaces cannot deal very well
+with descriptions of more than about 20 lines, so try to keep it below
+this limit.
+ <p>
+For specific rules depending on templates type (string, boolean,
+etc.), please read below.
+
+ <sect2>Choices
+ <p>
+This field should be used for Select and Multiselect types. It
+contains the possible choices which will be presented to users. These
+choices should be separated by commas.
+
+
+ <sect2>Default
+ <p>
+This field is optional. It contains the default answer for string,
+select and multiselect templates. For multiselect templates, it may
+contain a comma-separated list of choices.
+
+ <sect1>Templates fields specific style guide
+ <p>
+
+ <sect2>Type field
+ <p>
+No specific indication except: use the appropriate type by referring
+to the previous section.
+
+ <sect2>Description field
+ <p>
+Below are specific instructions for properly writing the Description
+(short and extended) depending on the template type.
+
+ <sect3>String/password templates
+ <p>
+<list>
+<item> The short description is a prompt and NOT a title. Avoid
+ question style prompts ("IP Address?") in favour of
+ "opened" prompts ("IP address:").
+ The use of colons is recommended.
+
+<item> The extended description is a complement to the short description.
+ In the extended part, explain what is being asked, rather than ask
+ the same question again using longer words. Use complete sentences.
+ Terse writing style is strongly discouraged.
+</list>
+
+ <sect3>Boolean templates
+ <p>
+<list>
+<item> The short description should be phrased in the form of a question
+ which should be kept short and should generally end with a question
+ mark. Terse writing style is permitted and even encouraged if the
+ question is rather long (remember that translations are often longer
+ than original versions)