You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@vcl.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2017/07/07 17:49:00 UTC

[jira] [Commented] (VCL-1058) User accounts not deleted on computer when removed from a server request admin or access group

    [ https://issues.apache.org/jira/browse/VCL-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16078429#comment-16078429 ] 

ASF subversion and git services commented on VCL-1058:
------------------------------------------------------

Commit 1801199 from arkurth@apache.org in branch 'vcl/trunk'
[ https://svn.apache.org/r1801199 ]

VCL-1058
Updated OS.pm::add_user_accounts. If state = 'servermodified' and the account already exists, it now calls either grant_administrative_access or revoke_administrative_access.

Updated Linux.pm::create_user
Cleaned up OS.pm::delete_user_accounts. It had 2 nearly identical loops with duplicated code.

Updated pre_capture in Linux.pm and Windows.pm to call delete_user_accounts instead of delete_user.

> User accounts not deleted on computer when removed from a server request admin or access group
> ----------------------------------------------------------------------------------------------
>
>                 Key: VCL-1058
>                 URL: https://issues.apache.org/jira/browse/VCL-1058
>             Project: VCL
>          Issue Type: Bug
>          Components: vcld (backend)
>    Affects Versions: 2.4.2
>            Reporter: Andy Kurth
>            Assignee: Andy Kurth
>             Fix For: 2.5
>
>
> 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.
> {color:red}*Users who are removed from the _admin_ group and added to the _access_ group retain sudo/root/Administrator access*{color} 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, {color:red}*user accounts added for server requests are not properly removed if an image or revision is captured for that server request*{color}.  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.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)