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

Serge E. Hallyn serge at hallyn.com
Sun Feb 20 17:55:12 GMT 2022


Well shucks.  I wonder whether anyone actually uses the adduser that
comes from shadow's contrib/ directory.  It's had no meaningful updates
in over a decade, so I think we should drop it.

-serge

On Sun, Feb 20, 2022 at 10:24:13AM -0500, Jason Franklin wrote:
> 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
> > 
> 
> 
> _______________________________________________
> Pkg-shadow-devel mailing list
> Pkg-shadow-devel at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel



More information about the Pkg-shadow-devel mailing list