User resource errors around the default group

[danielpodwysocki]

When changing a user's home directory outside of mgmt, we seem to immediately break the user resource and its handling - it starts producing usermod errors.

Steps to reproduce:

1. Run the below mcl:

user "mgmttest" {
	state => "exists",
}

2. in /etc/passwd edit the home dir to be mgmttest1
3. Run mgmt, see the error

Even setting the home dir back to mgmttest still causes the error.

Reproduced with latest main branch build of mgmt, on Ubuntu 24.04 (shadow-utils 4.13, which provide usermod erroring below)

Error:

17:21:42 engine: user[mgmttest]: Error: error during Process(): usermod: no options Usage: usermod [options] LOGIN  Options:   -a, --append                  append the user to the supplemental GROUPS                                 mentioned by the -G option without removing                                 the user from other groups   -b, --badname                 allow bad names   -c, --comment COMMENT         new value of the GECOS field   -d, --home HOME_DIR           new home directory for the user account   -e, --expiredate EXPIRE_DATE  set account expiration date to EXPIRE_DATE   -f, --inactive INACTIVE       set password inactive after expiration                                 to INACTIVE   -g, --gid GROUP               force use GROUP as new primary group   -G, --groups GROUPS           new list of supplementary GROUPS   -h, --help                    display this help message and exit   -l, --login NEW_LOGIN         new value of the login name   -L, --lock                    lock the user account   -m, --move-home               move contents of the home directory to the                                 new location (use only with -d)   -o, --non-unique              allow using duplicate (non-unique) UID   -p, --password PASSWORD       use encrypted password for the new password   -P, --prefix PREFIX_DIR       prefix directory where are located the /etc/* files   -r, --remove                  remove the user from only the supplemental GROUPS                                 mentioned by the -G option without removing                                 the user from other groups   -R, --root CHROOT_DIR         directory to chroot into   -s, --shell SHELL             new login shell for the user account   -u, --uid UID                 new UID for the user account   -U, --unlock                  unlock the user account   -v, --add-subuids FIRST-LAST  add range of subordinate uids   -V, --del-subuids FIRST-LAST  remove range of subordinate uids   -w, --add-subgids FIRST-LAST  add range of subordinate gids   -W, --del-subgids FIRST-LAST  remove range of subordinate gids   -Z, --selinux-user SEUSER     new SELinux user mapping for the user account  : exit status 2

[danielpodwysocki]

Attempting to modify the homedir in the above repro is a red herring. The error happens whenever mgmt reconciles a user resource with no extra arguments passed (see mcl example in the issue repro). It doesn't matter if we change it - this was just the trigger for the error where it was initially observed.

Restarting mgmt with no changes to the resource hits the same error.

I submitted a patch to handle that case here: #843

[purpleidea]

Thanks for the report!

The issue is actually quite complicated:

1. When we make a user we need to use --no-user-group so we don't get a random group we don't want ... But also it seems a user must have a primary user group.

2. So if we just add a user, or when we usermod, if we haven't specified at least one group, then we need to make sure to not see [] vs ["thatgroup"] since we'd always be false...

We want to keep it ergonomic so that:

user "james" {
        state => "exists",
}

is enough, even though it might secretly be equivalent to writing:

user "james" {
        state => "exists",
        group => "james",
}

or maybe:

user "james" {
        state => "exists",
        groups => ["james",],
}

Needs further thought, and definitely some tests.

[danielpodwysocki]

I'll have a look and see how far I can get it.

Since there can only be one primary group, I think defaulting to:

user "james" {
        state => "exists",
        group => "james",
}

When neither group nor GID is defined makes sense.

I think groups instead of group would make it harder:

• we'd have to default which one is primary from the ordering
• also usermod ignores the primary group when passing -G. It'd need extra logic for all that handling.