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

[Simon Chopin]

The issue was introduced with https://github.com/shadow-
maint/shadow/pull/237

Basically, the previous group validation was done using glibc's getgrid
directly, which was presumably coping well with the RO status of
/etc/group, but that poses consistency problems because you could add a
local user to a network group. That PR changed this to only check the
local /etc/group file contents manually instead.

Sadly, it doesn't cope well with our extrausers feature on multiple levels:
* The manual code fails hard if it can't lock the files
* We presumably have local groups defined in multiple places, which the code doesn't allow for.

A quickfix would be:
* Move the validation to until *after* parsing all of the options
* Revert back to the previous approach to validate groups if in extrausers mode

A more involved fix would be to replace that with an approach that would
check both /etc/group and the extrausers equivalent when validating
groups, while silently ignoring locking failures.

-- 
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:
  New

Bug description:
  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.

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