[
http://jira.magnolia.info/browse/MAGNOLIA-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18099#action_18099
]
Jan Haderka commented on MAGNOLIA-2388:
---------------------------------------
bq. if I add rights to read roles it doesn't mean I am adding the permission to
modify users, isn't it?
True, but each user always had and still has rights to modify their own
preferences.
bq. I don't think that granting each user a write permission to its own acls is
something desired...
See my comment above, each user always had the permission to modify child nodes
of themselves. If you check the core update task, we are adding just read
permission to the node itself (so they can see their own user name for example)
nothing more then that. The only reason why this worked before is because
displaying the dialog was done with system user privileges, and we removed this
now.
bq. well, I am pretty tired of getting harsh responses or seeing that most
decisions are taken individually and not open to discussions... anyway: this is
not the place to discuss this, sorry for the bad introduction
Agreed, I haven't tried to give harsh response here either, so sorry if it came
out as one. :) It might be more useful to get such discussions going in the dev
list or as Philipp mentioned while ago, we have scrum meeting every day at 2:30
at irc://irc.freenode.net/magnolia-dev and hang around there for most of the
day. It would be even better place to talk to avoid future misunderstanding and
to see (and to influence) day to day development.
Now lets try to have a fresh start. I'll try to explain how it works now and
why and we can take it from here.
prior 3.6.2:
* the security have been broken since the only protection from user assigning
themselves more rights was the (implicitly) hidden dialog.
* to bring up that dialog when you wanted user to be able to change privileges,
you had to do through extensive acl configuration to bring up
security/admin/username menu for given user.
from 3.6.2 onwards:
* the dialog is exposed (this is new) so users can change their own privileges
(by default, all except anonymous) (this right was always here).
* the above is configurable and where desirable, users can be taken away such
privilege (by making their own node read only) and they will not be able to
edit their own preferences any more (this haven't worked before 3.6.2 since the
dialog involved used system privileges in case of groups and roles)
* the display and assignment of the groups and roles is controlled by users
current rights in respect to roles and groups
* if user has assigned given role/group user gets read right to this
role/group via assignment.
* user can (un)assign only roles/groups he/she has rights to read
* 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)
* user can not assign role to themselves without having rights to read that
role (this is new in 3.6.2.) and without write permission to own acl_userroles
(same as before 3.6.2)
The main focus of the change was to allow editing privileges, close the present
security hole and to be backward compatible since this is a minor release.
I hope i managed to cover all unclear points in the above, if not, please
shout. If you see any obvious hole in the above, please shout as well.
> 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/
----------------------------------------------------------------
