[Pkg-shadow-devel] Bug#868568: Bug#868568: Bug#868568: Possible cause of deluser problem: subordinate user IDs

[Jason Franklin]

On Tue, 2022-03-08 at 18:39 +0000, Ben Harris wrote:
> On Tue, 8 Mar 2022, Serge E. Hallyn wrote
> 
> > So deluser was doing the right thing, right?
> > 
> > The bug is how you got into this state?  Either the adduser for
> > the high uid should have checked for it being a delegated subuid,
> > or the adduser which added the subuids to the lower subuid should
> > have refused when the higher subuid existed as a uid.
> 
> As far as I can see, there is no checking for collisions in either 
> direction: useradd depends on the ranges [UID_MIN,UID_MAX] and 
> [SUB_UID_MIN,SUB_UID_MAX] not overlapping, and issues a warning if you 
> assign a static UID outside the specified range.

Serge:

This is something that has recently gotten my attention in my adduser
maintenance efforts. I am trying to help where I can to work around it
and to collaborate with shadow on the issue to get at an optimal
solution.

adduser has its own UID ranges set in /etc/adduser.conf. These variables
are the ones that matter...

> FIRST_SYSTEM_UID=100
> LAST_SYSTEM_UID=999
> FIRST_SYSTEM_GID=100
> LAST_SYSTEM_GID=999
> FIRST_UID=1000
> LAST_UID=59999
> FIRST_GID=1000
> LAST_GID=59999

As far as I can tell, adduser has no concept of a "subordinate UID"
(neither do I for that matter). I was not familiar with this feature
until recently. This is something I'll have to read about.

The latest upload of adduser (v3.120) uses a naive technique of passing
through its own system user UID range settings to the useradd call. See
below...

  &systemcall('/usr/sbin/useradd', '-r',
      '-K', sprintf('SYS_UID_MIN=%d', $config{'first_system_uid'}),
      '-K', sprintf('SYS_UID_MAX=%d', $config{'last_system_uid'}),
      '-d', $home_dir,
      '-g', $ingroup_name,
      '-s', $shell,
      '-u', $new_uid,

This technique has the benefit that when you use "adduser" you make use
of adduser settings with no warnings from useradd. Likewise, using
useradd obviously still reads from /etc/login.defs.

However, it does not solve the problem that we have two places for the
settings to be specified. Maybe this is not as confusing as I think. The
adduser tool uses /etc/adduser.conf and useradd uses its own file. I
suppose it's on the user to know which file configures which tool.

Other than having adduser pass through its own settings to avoid
"useradd" warnings, I'm not sure what else can be done to reconcile this
divergence.  It has existed for a while.

Let me know if you have any thoughts! Thanks!

-- 
Jason Franklin