Jörn Nettingsmeier wrote:
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?
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.
hmm, ok, thanks for explaining again. i'm getting a little more
insight now. but i think the correct approach in the current situation
is to graft on a custom usecase that does what you need done, and
disallows privilege escalation [1]. i'm really uneasy with fundamental
ac semantics changes in a hurry during code freeze.
The problem is the core code has no method of preventing privilege
escalation. This is a severe fundamental vulnerability and it needs to
be fixed before being released. So I would need to override the existing
ac auth, ac archive, ac trash usecases to prevent the admin role from
being assigned. And after all of that, only I am protected, provided I
wrote my code good enough to block the core problem. What about the
average user? It is currently trivial (without the patch) to take alice
and make her admin due to how the default pub is shipped.
I agree it isn't good to have ac changes now. However, it's even worse
to ship with this vulnerability.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
