Tom
thats a lot to read ... I think that you have a point there somewhere,
and should discuss this on the dev-list. Maybe file a jira issue so
that your valuable points are documented there.
I always said somebody should come up with a better concept ;-)
re 3): yes currently references are not maintained, another issue that
is on the agenda
Thanks
Boris
On 11.10.2005, at 13:42, Tom Engel wrote:
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
----------------------------------------------------------------
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/magnolia/developer.html
----------------------------------------------------------------
