[Pkg-shadow-devel] Reconciling conflicts between methods for adding users
Jason Franklin
jason at oneway.dev
Thu Feb 24 00:29:29 GMT 2022
Hey, Lorenzo:
On Mon, 2022-02-21 at 18:26 +0100, Lorenzo wrote:
> > Through discussion on DBTS, 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.
>
> I'm aware of this, see #981917, but didn't have the time to deal with
> it yet
Fantastic! I did not know about this report. I guess I didn't search the
bug pages thoroughly enough.
I am glad that there is already some awareness of this.
> > So, the result is that we have three ways of adding users and system
> > users to a Debian box at the current time.
>
> If that was meant to be a comprehensive review of all ways to create
> system users in Debian, I'm afraid it's far worst than that: you
> didn't account for systemd-sysusers and dh_installsysusers[2],
> see also #962384[3], and there are 3 different packages that provide
> systemd-sysusers.
Wow! I did not expect there to be so many options. I clearly have some
more research to do here.
I am starting to see that having many options is the norm in Debian. It
was a tad confusing for me, though, when I started down this rabbit
hole.
> > 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 "!").
>
> This (and other parts too) is useful info, even if not complete, it
> help me to better understand the issue. Thanks :)
I am happy this was seen as helpful. I think that enumerating these
differences in how the tools behave is a good first step toward
collaboration.
As one of my next tasks, I plan to implement a set of functional tests
for what currently happens when someone invokes:
# adduser --system foo
... on Debian. This has been documented, see adduser(8), but a
functional autopkgtest will put clear assertions into Salsa where they
can be discussed point-by-point or referenced. Maybe the test(s) can be
applied to other methods of creating a user so that they can match.
> I don't think there is consensus on [how the various tools for
> creating system users should fit together]. I think there is a group
> of DD that want systemd-sysusers to become the the preferred method,
> while there is another group that disagree and prefers the status quo.
> I just want to make sure you are aware that you are stepping in
> the "inits Debian landmine".
Ah, I see. I did not understand that this was a point of such
contention.
For me as a contributor to and user of "adduser", I just want the tool
to improve in stability and helpfulness.
Playing nice with other tools is certainly a bonus from my point of
view.
> For now I think it would be more safe to say that " dh-sysusers is one
> of the available method for adding/removing system users in package
> maintscripts"
> On the other hand I'm not sure of how systemd-sysusers works, I doubt
> it (the C implementation) uses Debian's adduser.. but I'm just
> guessing, you need to hear from someone that is expert in systemd code.
I'll have to do some research here.
> > 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.
>
> Speaking of dh-sysusers, I'm ok switching from useradd to adduser, but
> the task is very time consuming for me (a lot of testing) so it won't
> happen superfast but before the next freeze is feasible.
I understand that time is required on your end. The effort would be
appreciated. Thank you for the willingness to consider this change.
Do feel free to reach out if you think I can help in any way.
For the time being, I'm just working on fixing bugs in "adduser" and on
improving functional test coverage as much as possible.
> hope this helps,
It does! Thank you!
--
Jason Franklin
More information about the Pkg-shadow-devel
mailing list