[
https://issues.apache.org/jira/browse/GUACAMOLE-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17852054#comment-17852054
]
Nick Couchman edited comment on GUACAMOLE-1957 at 6/4/24 2:15 PM:
------------------------------------------------------------------
[~shargan] There is a bit of nuance to this bug that I think is worth noting.
Originally I did not think it was a bug at all, but a little investigation
leads me to see what I think is actually at the core of it. However, I think
it's important to clarify the ways in which the permissions system is working
as designed:
* Users who have the right to create connections, whether as System
Administrators, or with the "Create Connections" permission, will be the
"owner" of that connection, and will have administrative rights to it. This
results in *four* permissions entries being created in the
guacamole_connection_permission table for this user/connection pair: READ,
UPDATE, DELETE, and ADMINISTER.
* Removing the "System Administrator" or "Create Connections" (et al) rights
does not - and should not - remove ownership of created connections or
permissions to those connections.
* The connections that the user created are shown at the bottom of the user
administration page as connections for which that user has permissions.
Again, all of those items are working as expected and intended. The only piece
of this that I believe makes this a bug is that, when you clear the checkbox
for that connection in the user administration page, only the "READ" permission
is cleared from the database - the remaining entries, for UPDATE, DELETE, and
ADMINISTER, are left in the database, resulting in the behavior you're seeing.
This means that:
* While the user cannot read the connection, and, so, cannot see it in the GUI,
there is still a chance that the user would be able to update, delete, or
otherwise affect it due to the fact that they retain other permissions to the
connection.
* If you add "READ" access back for the user, they will not only be able to
read (use, connect to) the connection, they will also be able to update it.
My opinion is that clearing the checkbox for the connection should clear *all*
of the permissions in the database for the connection (or other object), not
just the READ permission. However, this highlights another aspect of the
permissions system, and that's that the GUI only manages a small subset of the
permissions - for example, you cannot assign a user "Administer", "Update", or
"Delete" permissions to a specific connection, connection group, etc., in the
GUI - you have to manually create the entries in the database. There are some
limitations to the current setup. In this case, this is a bug that stems from
those (designed, or at least expected) limitations.
was (Author: nick.couch...@yahoo.com):
[~shargan] There is a bit of nuance to this bug that I think is worth noting.
Originally I did not think it was a bug at all, but a little investigation
leads me to see what I think is actually at the core of it. However, I think
it's important to clarify the ways in which the permissions system is working
as designed:
* Users who have the right to create connections, whether as System
Administrators, or with the "Create Connections" permission, will be the
"owner" of that connection, and will have administrative rights to it. This
results in *four* permissions entries being created in the
guacamole_connection_permission table for this user/connection pair: READ,
UPDATE, DELETE, and ADMINISTER.
* Removing the "System Administrator" or "Create Connections" (et al) rights
does not - and should not - remove ownership of created connections or
permissions to those connections.
* The connections that the user created are shown at the bottom of the user
administration page as connections for which that user has permissions.
Again, all of those items are working as expected and intended. The only piece
of this that I believe makes this a bug is that, when you clear the checkbox
for that connection in the user administration page, only the "READ" permission
is cleared from the database - the remaining entries, for UPDATE, DELETE, and
ADMINISTER, are left in the database, resulting in the behavior you're seeing.
This means that:
* While the user cannot read the connection, and, so, cannot see it in the GUI,
there is still a chance that the user would be able to update, delete, or
otherwise affect it due to the fact that they retain other permissions to the
connection.
* If you add "READ" access back for the user, they will not only be able to
read (use, connect to) the connection, they will also be able to update it.
My opinion is that clearing the checkbox for the connection should clear *all*
of the permissions in the database for the connection (or other object), not
just the READ permission. However, this highlights another aspect of the
permissions system, and that's that the GUI only manages a small subset of the
permissions - for example, you cannot assign a user "Administer", "Update", or
"Delete" permissions to a specific connection, connection group, etc. There are
some limitations to the current setup. In this case, this is a bug that stems
from those (designed, or at least expected) limitations.
> Permissions system behaving unexpectedly
> ----------------------------------------
>
> Key: GUACAMOLE-1957
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1957
> Project: Guacamole
> Issue Type: Bug
> Affects Versions: 1.5.5
> Environment: Guacamole and guacd installed using official docker
> images.
> Reporter: Adam
> Priority: Minor
>
> If an user have any administrative permissions assigned to him, either
> directly or inherited from a group, and created anything using this
> permissions (user, group, connection, etc.), he can make administrative
> actions on these items even after administrative permissions are detached
> from him directly or by removing from group from which these permissions were
> inherited.
> This effectively makes user a lifelong administrator of items he created,
> even after this user does not have these permissions anymore.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
