[
http://jira.magnolia.info/browse/MAGNOLIA-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18101#action_18101
]
Fabrizio Giustina commented on MAGNOLIA-2388:
---------------------------------------------
thanks Jan ;)
> * the dialog is exposed (this is new) so users can change their own
> privileges (by default, all except anonymous) (this right was always here).
perfect
> * the above is configurable and where desirable, users can be taken away such
> privilege
great.
My point here is that I can't see user and roles as "user preferences", they
are usually a completely different stuff. I would just modify this dialog (not
reusing the same one used for editing users) by removing the role/group
selector.
> user can (un)assign only roles/groups he/she has rights to read
ok, but just to make it stronger: can we assume the user must have both read
privileges on the groups/roles and write permissions on its own acls? And that
any user should not have a write permission on its own acl by default?
That's the main part of the whole that looks fragile, actually this all is
based to the fact that adding a role the user can't read doesn't work because
the save handler isn't able to convert the role name to a uuid.
nb: the problem of a "corrupted" user node if a user manually type a user role
he can't access is directly correlated, and pretty important to fix: neither
the superuser is able to fix a similar node, he can just delete it and
recreate. I assume that if we expose a field called "roles" we will end up with
tons of broken users. Who could resist to just try to write "superuser" if you
get proposed a similar form? ;D
(ok, it may be a user "mistake", but we should at least don't punish him too
much)
> assigning user explicitly read to whole userroles workspace is equivalent to
> assigning that user superuser role in respect to granting roles hence such
> user can assign any role (even to themselves). If you need user to be able to
> assign roles, but do not want such user to be able to assign privileges to
> themselves, you have to explicitly set acl_userroles of that given user to
> read only for that given user (again this is same as before 3.6.2)
understood, and my point is: let's remove the write privilege to the acl
subnode if not assigned by default. It's true that some of this problems were
also in previous versions of magnolia, but adding a edit dialog easily
accessible to any user surely could make the problem bigger.
Summing up, this are the improvement I would suggest:
- create a specific dialog for user preferences, without the group/role selector
- bugfix: if a wrong/unreadable role/group is manually inserted in the field,
don't break the user node, just don't assign such group/role
- make acls on the own user node not writable by default (so just making it
secure by default and allowing to change it if needed).
that's all, and I happily could take care of working at some of these if we
agree that it could be an improvement compared to what we have now...
(if we agree on some of these points we could split this discussion in small
specific tasks?)
> 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/
----------------------------------------------------------------
