Richard Frovarp wrote:
Jörn Nettingsmeier wrote:
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.
i still don't really understand the problem. iiuc, you want to allow
some of your users to access some usecases. of course, these usecases
must not include any that allow privilege escalation. now all you need
to do is introduce a new role "maintenance" or whatever, which is then
granted access to whatever usecases you need.
if this includes one that would allow privilege escalation, you will
have to write a slightly modified usecase that avoids this problem.
won't that solve your issue?
i agree we could think about this some more and provide a generally
useful solution, but only after it has been demonstrated to this bear of
very little brain that there really is a general problem, and only after
2.0.
--
Jörn Nettingsmeier
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
