Debian Bug report logs - #868568
adduser - deluser command says user has running processes when user has a custom UID assigned

[Message part 1 (text/plain, inline)]
Package: adduser
Version: 3.115
OS: Debian 9 amd64

Linux debian 4.9.15-x86_64-linode81 #1 SMP Fri Mar 17 09:47:36 EDT 2017
x86_64 GNU/Linux

dpkg -s libc6 | grep ^Version
Version: 2.24-11

Hello,

On a clean Debian 9 amd64 install the deluser command detects running
processes from the user I am trying to delete, while no processes are
running under that user. This is only the case when the user has a special
UID assigned.

Steps to reproduce on a clean Debian 9 install. I did this on a Linode upon
the first login with SSH as root:

adduser foo
adduser foo1234 --uid 101234
adduser foo1234 sudo
su - foo1234
sudo su -
# enter sudo password
deluser foo

This gives the following output:

root@debian:~# adduser foo
Adding user `foo' ...
Adding new group `foo' (1000) ...
Adding new user `foo' (1000) with group `foo' ...
Creating home directory `/home/foo' ...
Copying files from `/etc/skel' ...
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for foo
Enter the new value, or press ENTER for the default
        Full Name []:
        Room Number []:
        Work Phone []:
        Home Phone []:
        Other []:
Is the information correct? [Y/n] y
root@debian:~# adduser foo1234 --uid 101234
Adding user `foo1234' ...
Adding new group `foo1234' (101234) ...
Adding new user `foo1234' (101234) with group `foo1234' ...
Creating home directory `/home/foo1234' ...
Copying files from `/etc/skel' ...
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for foo1234
Enter the new value, or press ENTER for the default
        Full Name []:
        Room Number []:
        Work Phone []:
        Home Phone []:
        Other []:
Is the information correct? [Y/n] y
root@debian:~# adduser foo1234 sudo
Adding user `foo1234' to group `sudo' ...
Adding user foo1234 to group sudo
Done.
root@debian:~# su - foo1234
foo1234@debian:~$ sudo su -
[sudo] password for foo1234:
root@debian:~# deluser foo
Removing user `foo' ...
Warning: group `foo' has no more members.
userdel: user foo is currently used by process 4892
/usr/sbin/deluser: `/usr/sbin/userdel foo' returned error code 8. Exiting.
root@debian:~#
root@debian:~# ps aux | grep 4892
foo1234   4892  0.0  0.4  20936  4740 pts/0    S    17:54   0:00 -su
root      4917  0.0  0.0  12788   940 pts/0    S+   17:55   0:00 grep 4892

As you can see I am unable to delete the user foo because of the running
process with pid 4892, which is actually the process from user foo1234

When I do not assign a specific UID to the user foo1234 it works correctly
and as expected.

I also used specific UIDs in debian 8, and this issue did not pop up there.
It seems to be new in debian 9.

This is my first bug report to Debian so I hope all required information is
present and that you are able to reproduce it with the above steps.

Thanks,
Niels Hendriks

[Message part 2 (text/html, inline)]
Control: reassign -1 passwd

Hello,

I'm sorry for the delay. As far as Debian Unstable goes, I cannot
reproduce the issue on a clean VM, so it may be limited to Stretch as
you said. In any case, this part:

> root@debian:~# deluser foo
> Removing user `foo' ...
> Warning: group `foo' has no more members.
> userdel: user foo is currently used by process 4892
> /usr/sbin/deluser: `/usr/sbin/userdel foo' returned error code 8. Exiting.

shows that the error is coming from userdel. deluser issued the command
`/usr/bin/userdel foo` and userdel gave you this message. I'm therefore
reassigning this ticket to the passwd package, which is where userdel
comes from. You should hear from its maintainers as a result.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

I ran into a problem very similar to the one described in Debian bug 
868568: deleting a user with a UID < 100000 failed because of a process 
that was running as a user with a UID >= 100000.  It turned out to be 
because the larger user ID was recorded in /etc/subuid as a subordinate 
user-ID for the lower-numbered user.  Blanking out /etc/subuid and 
/etc/subgid caused deluser to behave as normal.

According to login.defs(5), the default range of subuids starts at 100000. 
If you're using UIDs over 100000 for normal users then you probably want 
to change that (or find a way to disable subordinate user-IDs entirely).

-- 
Ben Harris, University of Cambridge Information Services.

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.

On Tue, Mar 08, 2022 at 05:31:41PM +0000, Ben Harris wrote:
> I ran into a problem very similar to the one described in Debian bug 868568:
> deleting a user with a UID < 100000 failed because of a process that was
> running as a user with a UID >= 100000.  It turned out to be because the
> larger user ID was recorded in /etc/subuid as a subordinate user-ID for the
> lower-numbered user.  Blanking out /etc/subuid and /etc/subgid caused
> deluser to behave as normal.
> 
> According to login.defs(5), the default range of subuids starts at 100000.
> If you're using UIDs over 100000 for normal users then you probably want to
> change that (or find a way to disable subordinate user-IDs entirely).
> 
> -- 
> Ben Harris, University of Cambridge Information Services.
> 
> _______________________________________________
> Pkg-shadow-devel mailing list
> Pkg-shadow-devel@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel

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.

-- 
Ben Harris, University of Cambridge Information Services.

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

Debian Bug report logs - #868568 adduser - deluser command says user has running processes when user has a custom UID assigned

Debian Bug report logs - #868568
adduser - deluser command says user has running processes when user has a custom UID assigned