Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
2.4.2
-
None
Description
There are some problems regarding how user accounts created on a computer assigned to a server request are handled when users are removed from the a user group configured for the server request.
When a server request is loaded, users in both the admin and access user groups are added to the computer. When either of these groups is modified, either by specifying a different user group or by modifying the membership of a user group already configured for the request, the frontend triggers the backend to process the servermodified state.
Tracing through the code, all that is occurring when this state is processed is the execution of the OS module's add_user_accounts subroutine, which checks the server request groups and adds accounts as necessary.
Users who are removed from the admin group and added to the access group retain sudo/root/Administrator access because the code first checks to see if the user already exist. If so, it does nothing.
Conversely, users who were ever in the access group and added to the admin group do not get sudo/root/Administrator when they should.
In addition, user accounts added for server requests are not properly removed if an image or revision is captured for that server request. The pre_caputure subroutines in Linux.pm and Windows.pm are only calling the delete_user() subroutine which only deletes the user who owns the request. These should instead call delete_user_accounts() which deletes additional users in the server request groups.