[Bug 2063200] Re: useradd --extrausers --groups tries to lock /etc/group

Mauricio Faria de Oliveira 2063200 at bugs.launchpad.net
Mon Sep 2 14:52:18 UTC 2024


The autopkgtests in mysql-8.0/armhf seems to be timeouts (retried), 
and output mismatch (apparently the shutdown banner is unexpected).

The latter might need to be looked at.

mysql-8.0/armhf autopkgtests regressions (timeouts and output mismatch)

	9086s Completed: Failed 4/1073 tests, 99.63% were successful.
	9086s 
	9086s Failing test(s): main.lock_multi_bug38691 main.multi_update main.mysqlslap main.basedir

1)
	6152s [ 77%] main.lock_multi_bug38691                 w1  [ fail ]  timeout after 900 seconds
	6152s         Test ended at 2024-08-23 15:07:42

	6152s mysqltest: Could not open connection 'default': 2013 Lost connection to MySQL server at 'reading initial communication packet', system error: 104
	6152s safe_process[47785]: Child process: 47786, exit: 1
	...
	7088s Test main.lock_multi_bug38691 has failed 2 times, no more retries.

2)
	3607s [ 49%] main.multi_update                        w7  [ fail ]  timeout after 900 seconds

        4571s [ 59%] main.multi_update                        w7  [
retry-fail ]  timeout after 900 seconds

3)
	
	6000s [ 75%] main.mysqlslap                           w7  [ fail ]  timeout after 900 seconds

        6000s 2024-08-23T15:04:08.636678Z 734 [Note] [MY-010914]
[Server] Aborted connection 734 to db: 'bug58090' user: 'root' host:
'localhost' (Got an error reading communication packets).

4)
	1832s [ 21%] main.basedir                             w4  [ fail ]
	...
	1832s --- /usr/lib/mysql-test/r/basedir.result	2024-07-12 22:15:25.000000000 +0300
	1832s +++ /tmp/tmp.5Zzx61IMMy/var/4/log/basedir.reject	2024-08-23 16:55:42.443786800 +0300
	...
	1832s  # Supressing output for initialize:
	1832s +2024-08-23T13:55:33.808784Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.39-0ubuntu0.24.04.2)  (Ubuntu).
	1832s  # Wait for daemon server to start

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to shadow in Ubuntu.
https://bugs.launchpad.net/bugs/2063200

Title:
  useradd --extrausers --groups tries to lock /etc/group

Status in shadow package in Ubuntu:
  Fix Released
Status in shadow source package in Jammy:
  Invalid
Status in shadow source package in Mantic:
  Won't Fix
Status in shadow source package in Noble:
  Fix Committed
Status in shadow source package in Oracular:
  Fix Released

Bug description:
  [ Impact ]

  On Ubuntu Core 24 calling the command line

  useradd --extrausers --groups somegroup somenewuser

  ... fails with:

  useradd: cannot lock /etc/group; try again later.

  It worked on 22.04. /etc is not writable. It also fails if somegroup
  is a group in extrausers.

  [ Test Plan ]

  Part of the upload is adding an autopkgtest script testing useradd and
  usermod in the extrausers+readonly-etc case.

  In addition, the following commands should be run as root in a fresh
  container:

  ```
  # Install prerequisites
  apt install libnss-extrausers
  sed -i -r '/^(passwd|group|shadow|gshadow)/ s/$/ extrausers/' /etc/nsswitch.conf # enable extrausers in group, passwd, shadow and gshadow

  # Sanity checks of "normal" path
  groupadd etcgroup
  useradd --groups etcgroup etcuser
  id etcuser | grep etcgroup
  groupadd etcgroup2
  usermod --groups etcgroup2 etcuser
  id etcuser | grep etcgroup2
  useradd --groups nullgroup etcuser || echo Successfully rejected invalid group

  ls /var/lib/extrausers/ # should be empty

  # Sanity checks of "extrausers" path in rw context
  groupadd --extrausers extragroup
  useradd --extrausers --groups extragroup extrauser # currently fails
  id extrauser | grep extragroup
  useradd --extrausers extrauser2
  id extrauser2

  # Sanity checks of "extrausers" path in ro context
  mv /etc /etc-rw
  mkdir /etc
  mount -o bind,ro /etc-rw /etc
  groupadd --extrausers extragroup2
  useradd --extrausers --groups etcgroup extrauser3
  id extrauser4 | grep etcgroup
  ```

  Furthermore, validation from the Ubuntu Core team that this actually fixes
  their use case is required.

  [ Where problems could occur ]

  Regression potential is in the group validation stage of the `usermod` and
  `useradd` tools. Besides the usual risks related to C code, the various failure
  scenarios that come to mind are:

  * try to add the user to an non-existing local group, which would fail further
    down with a different error message
  * actually fail to identify a valid local group
  * Fail to either add the user to the system, or the user to the group
  * Update the wrong file (/var/lib/extrausers/* vs /etc/*)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/2063200/+subscriptions




More information about the foundations-bugs mailing list