[
http://jira.magnolia.info/browse/MAGNOLIA-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18095#action_18095
]
Jan Haderka commented on MAGNOLIA-2388:
---------------------------------------
bq. This is a leftover from MAGNOLIA-574 : since the task was closed ignoring
my comments
could you please leave self pity out? No one ignored your comments.
bq. Just create a user with a editor role and readonly access to userroles: he
can just type "/superuser" in its preference dialog to gain full access.
But this is exactly what you are telling system to do: if you add user read
rights to the userroles, you tell system that such user is allowed to read (and
reference) the roles and of course the system allows such user to read the
roles and therefore assign them to themselves or to anyone else for that
matter.
If user needs to read a role, then such user needs rights to read only role
assigned (and should get such rights together with the role assigned), but as I
can see it there is no reason why you should grant any user flat unrestricted
access to userroles.
Could you describe the scenario in which assigning read access to all roles
happens with default installation of Magnolia or in which such setting could
not be avoided?
Please note also that in previous versions, this was possible since there was
no checking and only prevention measure was hiding the dialog from the users.
To assess rights to assign roles based on the access rights to userroles
assigned to given user is IMHO the right thing to do instead of hiding the
dialog.
> Easy privilege escalation from user preferences
> -----------------------------------------------
>
> Key: MAGNOLIA-2388
> URL: http://jira.magnolia.info/browse/MAGNOLIA-2388
> Project: Magnolia
> Issue Type: Bug
> Components: security
> Affects Versions: 3.6.2
> Reporter: Fabrizio Giustina
> Assignee: Fabrizio Giustina
> Priority: Blocker
> Fix For: 3.6.2
>
>
> This is a leftover from MAGNOLIA-574 : since the task was closed ignoring my
> comments and no other task is listed for 3.6.2 I am adding this as a separate
> issue since IMHO magnolia 3.6.2 can't be released as is now...
> After the change in MAGNOLIA-574 and related now every user (at least with a
> read only access to the user repository) can self-change its role to
> superuser using the preference dialog linked to the user name.
> Just create a user with a editor role and readonly access to userroles: he
> can just type "/superuser" in its preference dialog to gain full access.
> The are multiple issues/tasks associated to this:
> - user should not be have read/write permissions to the acls by default, this
> should be strictly forbidden unless explicitely added by a superuser
> - the preference box dialog should not list group/roles (it makes no sense,
> just name me another app where users have a similar thing in their preference
> page!)
> - a bug in the bug: if the user enters a role he doesn't have read rights for
> in the preference page the user node gets corrupted and can't be edited
> anymore
> as previously discussed, IMHO a better solution would be allowing only
> readonly access to own user node by default and using a custom save handler
> for the preference page which allow editing of checked properties using a
> system operation. User preferences should use obviously a different dialog
> from the standard user edit dialog.
> Nobody else cares about this?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.magnolia.info/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/
----------------------------------------------------------------
