[
https://issues.apache.org/jira/browse/VCL-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Kurth updated VCL-1058:
----------------------------
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.
{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.
was:
There are some *major security 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. Nothing in this
subroutine checks for users previously added to the computer which are no
longer members of either of the server request user groups. As a result,
{color:red}users who were previously members of either the _admin_ or _access_
group will still have access to the computer when they no longer should.
*Previous members of the _admin_ user group will have sudo/root/Administrator
access*.{color}
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, {color:red}user accounts added for server requests are not being
properly being 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.
> 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)
