[BUG] system_usermanager.php: users not added to /etc/group

[mfedv]

on 20.1.8_1

TL;DR:

lines 386 and 387 in system_usermanager.php should be flipped
(create unix system user before changing its group settings)

--------------------

long story:

In System / Access / Users (system_usermanager.php), adding a new user
with activated entries in "Group Memberships" fails to add the
corresponding new unix system user to the respective unix system group
in /etc/group.

To remedy this, you would need to remove group membership in the GUI,
"Save", add group membership again, "Save".

Calls to "local_user_set_groups()" and "local_user_set()" in
system_usermanager.php apparently have the wrong order, trying to modify
group settings for the unix system user before it even exists:

/usr/local/www/system_usermanager.php:
     36 function get_user_privdesc(& $user)
    ...
    386             local_user_set_groups($userent, $pconfig['groups']);
    387             local_user_set($userent);
    388             write_config();

If the user has not existed before, this results in an error message in
/var/log/system.log:

    Jul 22 17:22:42 opnsense1 opnsense: /system_usermanager.php: The command '/usr/sbin/pw 'groupmod' 'admins' -g '1999' -M '0,2000,2006,2007,2010,2011,2012,2014,2015,2016'' returned exit code '67', the output was 'pw: user `2016' does not exist'


In a HA config, this bug is _not_ propagated to slave firewalls, they
will do the right thing:

master, wrong group settings:
    root@opnsense1:~ # grep testuser9 /etc/passwd /etc/group
    /etc/passwd:testuser9:*:2016:65534:testuser9:/home/testuser9:/bin/sh

slave, correct group settings:
    root@opnsense2:~ # grep testuser9 /etc/passwd /etc/group
    /etc/passwd:testuser9:*:2016:0:testuser9:/home/testuser9:/bin/sh
    /etc/group:admins:*:1999:root,mfedv,testuser9

Flipping lines 386 and 387 in system_usermanager.php is sufficient to
get the unix system user added to the right group in /etc/group the
first time.

Note however that in the special case of the "admins" group, the "gid"
field in /etc/passwd still has different values on master node
(nobody=65534) and slave node (wheel=0).

Hitting "Save" again on master node (even with no modifications at all)
then brings the "gid" to 0 on the master node, too.

Not sure though if gid="wheel" is needed/warranted, I have been using
(GUI) group "admins" ssh accounts on cluster nodes with different gid
settings for some time and have not noticed any difference in behaviour.


Regards
Matthias Ferdinand