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 "pas...@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@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel _______________________________________________ Pkg-shadow-devel mailing list Pkg-shadow-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel