Synced users get their comment from the 'comment' attribute, but synced
groups never get one, as only the name and the members of a group are
queried. With FreeIPA for example, groups are described with the
'description' attribute, which is then not visible in Proxmox VE.
Set the comment of a synced group to its description, if it has one.
Like for the attributes of users, an existing comment is overwritten
by the synced one, and kept if the group has no description, unless
'properties' is part of 'remove-vanished'.
Signed-off-by: Michal Fox <me@dualfroz.com>
Users of the PAM realm are users of the host system, and setting their
password runs usermod on the node handling the request. If the user
only got added to the PAM realm, but does not exist on the host, this
failed with:
change password failed: user 'jdoe' does not exist
which is confusing, as the user is shown in the user list of the web UI
and the message does not say that the user on the host is meant.
Mention the PAM user and the host system in the error message, so that
it reads:
changing the password of the PAM user 'jdoe' on the host system
failed: user 'jdoe' does not exist
The output of usermod is still added at the end, so this helps with its
other errors too.
Signed-off-by: Michal Fox <me@dualfroz.com>
When the OpenID login creates a user, or adds a user to groups from the
groups claim, it writes these changes to user.cfg. The permissions it
returns for the web UI however got computed with the copy of user.cfg
the RPC environment loaded at the start of the request, which does not
know about the new user or group memberships yet.
So a user logging in for the first time got no permissions from the
ACLs of its groups in this session, and buttons like "Create VM" stayed
disabled, until the next login. The same happened to existing users on
the login that added them to a new group.
Add a helper to reload the user config of the RPC environment, and use
it after the login changed user.cfg, before computing the permissions,
as suggested in the bug.
Add a test for both cases, which mocks the OpenID provider and keeps
user.cfg in memory.
Signed-off-by: Michal Fox <me@dualfroz.com>
Both plugins rejected the password with a plain boolean check, and in
Perl the string "0" is false. So a user whose password is "0" could
never log in, getting a generic authentication failure.
Only reject undefined or empty passwords.
Signed-off-by: Michal Fox <me@dualfroz.com>
dualfroz