Jörn Nettingsmeier wrote:
[EMAIL PROTECTED] wrote:
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED
COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=43915>. ANY REPLY
MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG
DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43915
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED Resolution|
|FIXED
------- Additional Comments From [EMAIL PROTECTED] 2007-11-21 03:17
------- I introduced a method Role.isAssignable() and a role
"sitemanager" with a group of the same name. All users have to update
their policies accordingly.
Please test and re-open if this doesn't resolve the issue. TIA!
hmm. i don't like this patch at this point in tíme.
if i understand richard correctly, he has been handing out the admin
role to users, thinking that they are limited to the subtree they are
given. but this opens the hole that a user can browse there and then
call admin usecases to escalate his/her privileges. if this is correct,
read on, otherwise i've misunderstood something, so ignore me.
i think this is basically a documentation bug. what's needed for this
usage scenario is a new role like you introduced, but this is something
that users can do themselves, tailored to their needs. why do we need a
new method (e.g. a *fundamental* change to the AC API), and why should
everyone have to update their policies during code freeze?
sorry if i've had a lot of criticism to offer lately, and not much help,
but i'm drowning in work... i think we should tie up what we have and
not get into any new things that are not really bugfixes.
You are somewhat correct. It is a question of functionality. In my usage
scenario, it makes sense to give a user the rights to change ac auth for
their subtree, or allow them to change a node name or visibility of a
node. Without the patch, I can't do that.
Let's say it is a documentation issue and we want to allow that
functionality. I then allow reviewers the rights to those usecases. They
can then go into ac auth, give themselves admin rights. Presto, they can
get into the admin area.
So basically, we need the additional method to protect against this sort
of thing so that the admin role can't be assigned via ac auth. Or we
have to hack the code to make it so that ac auth, ac archive, ac trash
only allow admins and no other roles. That would mean hacking the
usecases admin interface to prevent this. I think this was a clean fix
to a dirty security issue.
Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
