Hi!

Currently, Policy does contain guidelines about system accounts being
created on package installation. It is, however, more reluctant to give
advice about accout deletion on package uninstall and/or purge. In
Addition, the existing advice is somewhat hidden in chapter 9.2.2
documetning UID and GID classes.

There is the requirement that a purged package vanishes completly. There
seems to be consensus about this being not a good idea regarding account
deletion since noone knows whether the local admin has given some files
to the package account which would be left around unowned (and could
even suddenly belong to a new account that was creatd with the same
UID).

There are way over 514 packages matching "adduser.*--system" on
codesearch.debian.net, but just 125 packages containing
"deluser.*--system". I didn't check in all details whether all of those
matches are in maintainer scripts, but I think that this gives a rough
overview how many packages do not delete their account at the current
time.

How about putting advice like this in policy:

Suggestion 1:
Create a dedicated chapter (which would ideally be placed between the
current chapters 9.2.1. Introduction and 9.2.2. UID and GID classes)
named "dynamically allocated system users or groups for packages" with
the following contents:
- packages can create users and groups on installation
- usernames should be chosen wisely, allowing to deduce the related
  package from the name, and prefixed with an underscore
- adduser --system is the preferred method to create package account, it
  takes responsibility of being policy compliant. Other packages doing
  this job might exist (dh-sysuser, for example).

Suggestion 2a:
Document that a package should not delete its user on uninstallation
and/or purge. This reflects current practice of most packages but might
need changes in some packages that currently delete their user. Those
packages are the reason that this policy item should not be introduced
as a MUST.

Suggestion 2b:
Document that a package may lock its user on uninstall, but leave it on
the system on purge. That way, a leftover account could not be used as
an attack vector and just blocks the uid/gid and the name. On
reinstallation of a package, the existing, locked account would just be
unlocked.

This would be a new behavior that could be worth documenting in Policy.
Should the policy editors indicate that this might be an option, adduser
would be willing to implement a deluser --lock --system option that
would lock a named account if its uid is in the appropriate range for
system accounts, and adduser --system would not error out if the account
already exists and would just remove the lock. Thus implementing this
option in a package would just mean to add the appropriat deluser call
to postrm uninstall while postinst can remain unchanged.

transparency advice: I am on the adduser maintainer team and have the
longest track history of caring for adduser of all active team members.

I am willing to suggest wording, but I am not a policy expert and
wording would probably be better if an experienced policy editor would
write the appropriate language. How would a new chapter be inserted in
Policy without destroying existing references to chapter numbers?

I would like to hear your opinion on that. Thanks for considering.

Greetings
Marc

Hello Marc,

This sounds good, though we would need an extremely strong argument for
inserting rather than appending the new section -- we do not want to
renumber sections not just because it breaks hyperlinks, but because it
breaks purely textual references to Policy sections in bugs that remain
open, mailing list posts to which people still refer, etc.

It would be good to get some input from people who use other methods.  I
would always look to adduser myself, but there might be others who feel
strongly that it's not right for certain classes of case -- perhaps we
want to limit the scope of this advice a bit.

Sounds good.

Sounds like a nice improvement on the current situation.

Please go ahead and write a patch.  The Policy Editors are happy to
review and edit proposed wording but we can't be responsible for
producing all of the text that gets added to Policy.

thanks for pointing this out. I have made some notes (both for adduser
and for policy) from that bug.

Adduser development has regaind momentum, so I see it possible that we
get the necessary adduser changes in Debian before bookworm so that we
can, as a second step, amend policy and debhelper.

Please expect me to come up with suggested wording for policy that
referes to some adduser features that do not yet exist, but with my
adduser hat on, I will do my best to have those features implemented
before the suggested wording can be included in Policy.

Greetings
Marc

This is my patch.

I took care to not change policy chapter numbers, especially 9.2.2 has
remained 9.2.2. 9.2.1 has grown two subchapters.

diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
index 83b71b1..46f4441 100644
--- a/policy/ch-opersys.rst
+++ b/policy/ch-opersys.rst
@@ -214,30 +214,92 @@ Users and groups

 .. _s9.2.1:

Hi Marc,

I like your patch. :) I just have one comment:

unpredictable or non-deterministic allocation of such ids is a cause of non-
reproducibiliy for Debian images and installations, so us reproducible folks
would like to see "sensible" to be expanded to take reproducible builds into
account.

So we should go (in Policy) more towards "dynamic global UIDs and GIDs
which may post additional load towards the base-passwd maintainers?

Or would it be enough for reproducible images if adduser would finally
implement #243929, making it possible to pre-determine UIDs before an
image is built?

Greetings
Marc

I guess so, yes. :/

for reproducible images it would be 'enough' but I believe this would also shift
the burden of the work to each and every image designer, so in a way this feels
like a workaround with the main purpose of removing load from base-passwd
maintenance while putting load on everyone else forever :/

Roland Clobus has put a lot of work & thoughts into reproducible images, so I've
added him to cc: now, so he can comment on this aspect of #1006912.

Policy editors, I think we can now choose between taking care of the
needs of reproducible images right with this policy change or do
de-scope this temporarily until we have settled on the new wording
(which also includes some definitions) and then handle this in a second
change. I think the second change also needs the base-passwd people in
the loop.

How would you prefer to do this?

Greetings
Marc

I've read #243929 and #1006912.

For reproducible images (based on live-build) the order of the creation
of each user is determined by the order in which the packages are
installed. When the image is built, it starts with the default user
list, which is then expanded by the packages as they are installed.
When, while (re-)generating an image, an account is deleted, it will
also be in a deterministic order.
So from the viewpoint of reproducible images, it does not matter in
which order the lines in  /etc/passwd are, nor whether the same UID
number is assigned to a username.

With kind regards,
Roland Clobus

Hello,

The latter, please, assuming I'm not misunderstanding and the first
change makes things worse on the reproducibility front.

I am not a native speaker, but in my understanding my proposed wording
does not change the way we're creating UIDs right now, just clarified
terminology and explicitly writes down how things are done now, and
Roland confirmed that the current image process doesn't care about
numerican UIDs at all since they already make sure that package
installation happens in a pre-defined order.

That being said, an upcoming adduser change will allow local
administrators (including image creators) to pre-define the numerical
UIDs before the actual account gets created. This, however, does not
influence the order of accounts listed in /etc/passwd, for this to be
reproducible, the passwd / shadow package should make sure that their
user database files are sorted.

Greetings
Marc

That obviously didn't happen for bookworm, and neither for trixie, but
we're working on it. The policy patch still looks good and valid, so
we're still waiting for adduser to come up with the changes.

Thanks for your patience and for not holding your breath.

Greetings
Marc

Es gibt eine Familienspende in Höhe von 1.850.000,00 USD von Cheng Charlie
Saephan. Bitte antworten Sie für weitere Informationen. Denken Sie daran,
Ihrer Familie und den Bedürftigen in Ihrer Umgebung Gutes zu tun.

Dies ist bereits der zweite Versuch, Sie zu erreichen. Bitte antworten Sie
für weitere Details.