adduser in Debian
=================

The adduser package includes the adduser and deluser commands for
creating and removing users and groups.

The code in this package is intended as a policy layer, making it easier
for package maintainers and local administrators to create local system
accounts in the way Debian expects them to be created, taking the burden
to adapt to the probably changing specifications of Debian policy.

adduser --system is designed such that it can be called without the
caller needing to check that relevant pre-conditions have been met.

adduser --system take special attention on just needing a single call in
the package maintainer scripts without any conditional wrappers, error
suppression or scaffolding.

adduser honors the distinction between dynamically allocated system
users and groups and dynamically allocated user accounts that is
documented in Debian Policy, Chapter 9.2.2.


Documentation
-------------
This document contains background information that you might find
helpful to understand some of the design decisions that the adduser
maintainers took to bring adduser to where it is at the moment. For
operational reference, you might want to look at the manual pages that
come with the package (see apropos adduser, apropos deluser).


Usage in maintainer scripts
---------------------------
The reference to create users and groups related to packages is
Debian Policy, Chapter 9.2.2. adduser --system can help you to create a
user in your postinst. 

The most important thing to know is that adduser --system is idempotent:
If the desired user already exists with the important properties
matching, adduser returns a zero exit code and leaves the existing user
untouched.

We might consider it a bug if your maintainer scripts need scaffolding
around an adduser/deluser --system call in your maintainer scripts other
than checking for the executable being present in postrm. Please file a
bug if your package needs an if or other bracket around your adduser
calls.

See adduser(8) for more documentation about how adduser --system behaves
regarding uid, group membership, shell, and home directory. Consider
whether it should be possible to run processes or even log in as your
user and configure it appropriately.

We are currently (summer 2022) re-working adduser's logging subsystem
with the ultimate goal of adduser becoming silent in the process of
creating a system user unless the loglevel is raised by configuration or
an error happens.

It might be adviseable to not delete your users on purge of your package
since there might still be files belonging to the user. Instead, lock
your user, making it impossible to log in as the user, and unlock it in
postinst when your package gets reinstalled.

Sadly, currently (summer 2022, adduser 3.125) locking and unlocking
accounts it not well supported yet. We are planning to improve this in
time for the release of Debian bookworm.


Configuration files
-------------------
adduser and deluser have configuration files, /etc/adduser.conf and
/etc/deluser.conf, respectively. In a freshly installed package, both
files only contain comments, giving terse explanation about available
configuration options and stating what the default is that adduser and
deluser will use if not otherwise configured.

Both configuration files are dpkg-conffiles and have full conffile
support by dpkg on upgrades. Until Debian bullseye, /etc/adduser.conf
was managed by the maintainer scripts and debconf; this has been removed
in adduser 3.125 and the file was moved to being a dpkg-conffile.


Debconf
-------
Debconf support was removed in adduser 3.125. We used to just ask one
question during installation regarding DIR_MODE (system-wide readable
home directories or not).

With adduser growing, this has shown to pose issues since we did not
find an explanation to only give these limited choices in debconf. To
be consistent, we would have to add many more questions. This does not
seem to be a realistic endeavour given the available personpower.

Consequently, debconf support was removed complete, making
/etc/adduser.conf a regular dpkg-conffile.

We might be willing to reintroduce more elaborate debconf support in the
future if somebody volunteers to write the code, documentation and
tests, and to actually maintain it for the foreseeable future. Please
get in touch with the adduser team if you're willing to help.


Why not declarative?
--------------------
Adduser is intended to be used in maintainer scripts. While there are
approaches in Debian to move more and more functionality away from
maintainer scripts to a more declarative approach. The current form of
adduser is used in many hundred packages.

It is fine to use a more declarative approach to define system users in
Debian pacakges. There is nothing that forces package maintainers to use
adduser to create their package-related users. The packages dh-sysuser,
opensysusers, and systemd-sysusers already offer a declarative approach
to create package-related users.

For the time being, adduser's paradigm is not going to change for
compatibility's sake.


Directory services and adduser
------------------------------
We have been planning to convert adduser to a more modular approach,
allowing adduser to be used to create users in a directory service such
as NIS, NIS+ and LDAP, for more than two decades. It is not realistic to
expect this to happen any time soon.

For the time being, adduser is officially deprecating any existing
support to write to directory services. An arbitrary server in an
organization that uses a directory service is unlikely to have enough
privileges to write to a directory service anyway.

It might be possible, to add the Desired support via an adduser.local
hook. If you need more hooks to locally implement what you need, let us
know and we will see what we can do for you. A more flexible hook system
might be implemented in the nearer future.

We might be willing to reintroduce support for directory services in the
future if somebody volunteers to write the code, documentation and
tests, and to actually maintain it for the foreseeable future. Please
get in touch with the adduser team if you're willing to help.


Default for DIR_MODE
--------------------
DIR_MODE and SYS_DIR_MODE specify the file mode bits for a home
directory created by adduser. This has been a controversial setting
throughout most of adduser's life since the 1990ies.

Currently, DIR_MODE defaults to 0700, while SYS_DIR_MODE defaults to
0755. The separation between DIR_MODE and SYS_DIR_MODE happened in
adduser 3.122 because we got convinced that a normal user needs a
different setting than a system user. This allowed us to tighten the
file mode bits of a regular user's home directory to 0700 while keeping
the mode permissive setting for system users.

Historically, the separation was also implemented to finally solve
#643559, which requested setting the sgid bit for the home directory of
a non-system user by default, in order to ease setting access
permissions of shared workspaces in multi-user systems.  This default
has oscillated back in forth in adduser multiple times since the
1990ies, because both ways to set this bit by default have advantages
and disadvantages.  After a preliminary request for comment (see
https://lists.debian.org/debian-devel/2022/03/msg00098.html), the
default value for DIR_MODE was changed to 2700 in adduser 3.122 (July
2022).  Sadly, though the technical reasoning for NOT setting the bit
did largely not survive the last two decades, some use cases that we
were not fully aware of were adversely impacted by this change.

Promptly, #1014901 was filed, requesting that DIR_MODE be changed to
0700, effectively causing home directories of non-system users to be
created without the sgid bit. The biggest point in the reasoning is that
having the sgid bit set will need special measures to keep the home
directory's group ownership from propagating to file system images,
chroots, and archives, causing wrong file ownership/permissions in those
entities, which in turn might propagate to different systems and cause
security-related effects there.  The bug report gives instructions to
reproduce the behavior.

System administrators who run multi-user environments which require
shared workspaces have tools at their disposal to change the default
behavior as their individual needs require, and likely are aware of how
to work around any issues that arise as part of that configuration; it
is also very possible that such systems may be managed using
configuration management software. In an age of general purpose use on
one end, and single purpose containers on the other, this is unlikely to
be the majority of newly installed systems.

So what remains is the decision to provide a sane default for a system
that is installed by an end-user, who may not understand or be aware of
this setting at all, but who still might use Internet HOW-TOs to build
chroots, images or archives, inadvertently causing security issues on
third-party systems. The clear and unsurprising solution is to leave the
sgid bit for newly created users off by default. This is also important
to keep the support effort for other packages down. Users surprised by
the behavior might file bugs against other packages, increasing the
effort necessary to support those other packages.

So, in adduser 3.123, DIR_MODE reached its final default setting of
0700, flipping the default for the sgid bit one last time to the value
we had for the majority of Debian's existence period. With this change,
Debian is re-joining ranks again with ALL other major Linux
distributions, none of which setting the sgid bit on home directories to
1 (research done in July 2022).

This primarily affects the one user that can be created in the Installer
before there is any possibility to configure adduser. Those users will
now again have the sgid bit of the home directory set to 0. Again,
system administrators have the tools and documentation to configure
their systems as their individual requirements dictate (using the
DIR_MODE setting in adduser.conf, and/or fixing those initial
directories).

As mode 0700 provides both the most secure, unsurprising default, and is
in line with most other major distributions, the adduser team considers
the matter to be settled; any further discussion should come prepared
with rationale, support, convincing use cases and a significant public
discussion period.



Rewrite
-------
adduser needs a rewrite. The code base was started in the 1990ies and
this fact can easily be seen. The introduction of our test suite has
made changes to adduser much easier, but the code is still 25 years old.

We support any effort for a rewrite, but we strongly believe that this
should be done in a dedicated project with a new name, such as
adduser-ng or adduser4. But such a project needs to be externally
driven.



Participating in development
----------------------------
adduser is developed on
[Salsa](https://salsa.debian.org/debian/adduser). Our main communication
channel is the [Debian Tracker Package Mail
Address](mailto:adduser@packages.debian.org). You can subscribe to the
messages through the [Debian Tracker Package
Page](https://tracker.debian.org/pkg/adduser). If you want to
participate, create an account on Salsa, clone the Debian/adduser
project and submit a Merge Request. Feel free to use Salsa CI to have
your work tested automatically when you push.

Adduser has a test suite. If you implement new features, please also
write appropriate test cases and test them. Don't forget to adapt the
documentation and the manual pages. If you fix a bug, please write a
test case first that fails because of the bug, put the test case in its
own commit, and then implement the fix. We want to see the test fail
when just the test commit is cherry picked.

Working with branches and merge requests means rebasing a lot. To make
this easier, please don't squash your work into one huge commit. 
Use small, independent commits that can easily be understood. It is ok
to rebase or force-push to your development branch even after opening
the merge request. We love merges that can be pulled into master as a
fast-forward merge.

adduser should be coded according to the style suggestions given in
perldoc perlstyle. Indentation should be in increments of four
characters per level, using spaces, not tabs.



Credits
-------
This document was compiled by the adduser maintainers. Ximon Eighteen
helped to polish the language of the first revisions in August 2022.

