[Pkg-shadow-devel] Reconciling conflicts between methods for adding users

[Jason Franklin]

Replying so that this message is sent to the proper mailing list for
Shadow maintainers.  Shadow maintainers please read below!

I initially sent to "passwd at packages.debian.org", but that message was
rejected since I needed to subscribe to the preferred mailing list for
developers of the "shadow" package.

-- 
Jason Franklin

On Sun, 2022-02-20 at 09:56 -0500, Jason Franklin wrote:
> Dear Maintainers:
> 
> My name is Jason Franklin, and I am somewhat new to contributing to the
> Debian project.
> 
> I have taken it upon myself to help Marc Haber with some of the
> maintenance tasks needed in the "adduser" package. This includes fixing
> and closing old bugs and adding a new test suite. The test suite being
> the most important new addition!
> 
> Marc has done a great job of mentoring me and reviewing my PRs, and we
> expect to upload a new version of "adduser" soon that will have many
> minor bugfixes and tests. Finally some progress!
> 
> Through discussion on DBTS[1], it has become obvious that review is
> needed regarding what Debian tools are proper for adding and managing
> user accounts in various contexts.
> 
> Ricardo Fraile posted a summary of the options, which I have edited and
> quoted below...
> 
> > ... "adduser" is the recommended way to handle accounts in maintainer
> > scripts[1]. Debian Code Search reports 267 packages using it[2]. Yet,
> > "dh_sysuser"[3] seems to handle the same task and works with "useradd"
> > under the hood too.
> > 
> > [1] https://wiki.debian.org/AccountHandlingInMaintainerScripts
> > [2] https://codesearch.debian.net/search?q=path%3Adebian%2F*postinst+adduser&literal=1&perpkg=1
> > [3] https://manpages.debian.org/testing/dh-sysuser/dh_sysuser.1.en.html
> 
> So, the result is that we have three ways of adding users and system
> users to a Debian box at the current time. They all conflict in subtle
> ways. For example: UID/GID ranges are configured in both /etc/login.defs
> and /etc/adduser.conf at the moment. Another example: Creating a system
> user with adduser allows login with an SSH key (password is "*"), but
> login is completely disabled with useradd (password is "!").
> 
> The above issues seem pretty important and should be resolved before the
> next official release, I would think. Further, I am sure that there are
> other conflicts that I have yet to find.
> 
> The purpose of this email is to raise awareness of this issue and start
> a discussion in the direction of reconciling any conflicts that may
> exist between these tools. Please feel free to forward/CC anyone in the
> project who may be concerned with this topic!
> 
> I hope to establish a clear role for each of these tools so that the
> overlap is minimal. Here's how I see the tools fitting together:
> 
> 1. "useradd", etc., is the actual implementation of user/group
> addition/removal. It is installed on systems to do the actual work of
> local user account creation and destruction. Admins and package
> maintainers have access to these tools when they do special things, but
> they usually don't invoke them directly. These tools may, in fact, be
> considered more "distribution-agnostic" and not particular to Debian,
> but to the Linux ecosystem in general.
> 
> 2. "adduser", etc., is a wrapper on "useradd" that is Debian-specific
> and enforces Debian policy. It can add nice Debian embellishments that
> upstream "shadow" does not want to include or support. E.g., avoiding
> UID/GID re-use or forbidding certain UIDs prohibited by policy.[2]
> Features like backing up home dirs and mail spools and disabling/backing
> up/removing at and cron jobs can be provided where desired and where
> maintenance is not too burdensome. The idea is that "adduser" goes above
> and beyond in account creation and destruction to ease maintenance on
> the end host. This can be managed with adduser-specific configuration,
> of course.
> 
> 3. "dh-sysuser" can become the preferred method for adding/removing
> system users in package maintainer scripts. It may be that this could be
> modified to call "adduser/deluser" instead of "useradd". Not sure of how
> to resolve this or of what willingness there is to change. The problem I
> see is that using the helper currently results in different behavior
> than one would normally see historically from a package that called
> "adduser/deluser" (which used to be and still is customary). This is
> most obvious in that an "adduser" system user can log in with an SSH key
> and not so with "useradd" system users. At my day job, we have many
> package maintainer scripts using "adduser" and placing a public SSH key
> to allow login for the account from remote boxes. Also, system accounts
> made with "adduser" go in "nogroup" by default, yet they get a user-
> private-group with "useradd".  Yet more differences to consider.
> 
> This is the summary I have for now. I'm sure that you all will know much
> more of these discrepancies than I do currently.
> 
> I think that there is a lot of room for improvement here, and I know
> that collaboration will help things.
> 
> If you made it here, thank you for reading!
> 
> I look forward to hearing everyone's thoughts. :)
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004710
> [2] https://www.debian.org/doc/debian-policy/ch-opersys.html#uid-and-gid-classes
>