ok, I continued to play around with the roles and the ACLs and I see a
bit clearer. But in my opinion there is still a bug when assigning more
than one role to a user. See point 2 for that.
1. the roles pre-defined in 2.1 should explicitly grant access to needed
buttons
The roles pre-defined in the 2.1 wars explicitly deny access to buttons
that should not be shown to that role, but don't grant access explicitly
to the other buttons that are needed to fulfill the rights granted to
that role. So, assigning two roles to a user gives the user the rights
of both roles but can lead to a scenario where the user can't see any
single button necessary to do his job.
For example take developer and securitymanager:
- develper-role explicitly denies access to user-button and roles-button
- securitymanager-role explicitly denies access to config-button and
website-button
A user who has both of these two roles ends up with seeing not a single
button necessary to do his job.
IMO the roles should better be defined as follows:
- develper-role explicitly denies access to user-button and roles-button
but also explicitly grants access to config-button and website-button
- securitymanager-role explicitly denies access to config-button and
website-button but also explicitly grants access to user-button and
roles-button
Defining roles this way should lead to a user (having both of the roles)
that can see all of the four buttons. But this is not the case either
and imo this is a bug since the user sees different buttons depending on
the order of the roles assigned to the user (see point 2)
2. the order of the roles assigned to a user make a difference, but
should really not!
I tried the following:
a) create a role 'fullwrite' with
- read/write access to the whole website from root on (in acl_website/0:
path=/*, permission=63)
- read-only access to the whole config from root on (in acl_config/0:
path=/*, permission=8) This is just to make sure every button is shown.
b) create a role 'readonly' with
- read-only access to the whole website from root on (in acl_website/0:
path=/*, permission=8)
- read-only access to the whole config from root on (in acl_config/0:
path=/*, permission=8) Again, this is just to make sure every button is
shown.
c) complete the following steps:
- create a new user and assign both roles to that user: first the role
'fullwrite' then the role 'readonly'
- log in with that user, have a look to the website-tree
- normally I would expect, that the user has full read/write access to
the whole website, because he is a member of the role 'fullwrite'
- here with me the user is not able to edit the pages, only read-right
is granted
- log out
- change the order of the roles assigned to that user: first the role
'readonly', than the role 'fullwrite'
- log in again with that user, have a look to the website-tree
- now here with me the user has full read/write access (that's the way
it should be)
So, as it seems to me the effectiv rights a user has clearly depends on
the order of the roles assigned to that user. This leads to problems,
when two or more roles define different rights to the same paths.
Normally the less restrictive one should be granted, here the last one
is granted.
3. Question: references are not updated at all?
When I rename a role, the assigned rolenames in the user-object are not
updated and the user may not be able to log in anymore. Is this only
with roles or are references not updated at all when you rename a node
that can be linked to?
Regards,
tom
Tom Engel schrieb:
Hi list,
I had some problems here with users having more than one role, because
it seems that Magnolia doesn't get along very well with ACLs defining
different access rights to the same path. I'm not to sure if ACLs that
point to the same path are compared at all, but somehow it seems to
me, that always only the most restrictive rights to a path are granted
. Maybe that's the way it is intended to work, but imho this is more a
bug than a security feature. But step by step...
The new roles pre-defined in 2.1 limit access to the menu buttons,
(see http://magnolia.sourceforge.net/advanced/menu.html) so that the
members of a special role only see the buttons that belong to the
rights defined in the role. This is quite a nice feature, but can
result in conflicts when a user belongs to more than one role. It can
happen, that different ACLs of two roles to the same button-path
exclude each other and then for the member of both of the roles the
button is not shown in authoring instance. This can lead to users that
have a lot of rights but can't do anything in admin-gui, because they
don't see the buttons. The only way to fix that up I found till now is
to show each button to each role, which is not that of course.
Normally the rights of different roles should be added up, so that the
less restricting ACL should take into effect when there is more than
one ACL to a certain path. Is this a bug or is this a sort of security
feature I just don't get?
Regards,
tom
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/magnolia/developer.html
----------------------------------------------------------------
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/magnolia/developer.html
----------------------------------------------------------------
