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

Steve Langasek 2063200 at bugs.launchpad.net
Fri May 24 21:52:36 UTC 2024


Hello Valentin, or anyone else affected,

Accepted shadow into noble-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/shadow/1:4.13+dfsg1-4ubuntu3.1 in a
few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
noble to verification-done-noble. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-noble. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Description changed:

  [ 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
- vim /etc/nsswitch.conf # enable extrausers in group, passwd, shadow and gshadow
+ sed -i -r -e'/^(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
  usermod --extrausers --groups extragroup extrauser2
  id extrauser2 | grep extragroup
  
  # 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
  usermod --extrausers --groups extragroup2 extrauser3
  id extrauser4 | grep extragroup2
  ```
  
- 
  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
+   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/*)

** Changed in: shadow (Ubuntu Noble)
       Status: In Progress => Fix Committed

** Tags added: verification-needed verification-needed-noble

-- 
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 Committed
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 Committed

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 -e'/^(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
  usermod --extrausers --groups extragroup extrauser2
  id extrauser2 | grep extragroup

  # 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
  usermod --extrausers --groups extragroup2 extrauser3
  id extrauser4 | grep extragroup2
  ```

  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