Richard Frovarp wrote:
Jörn Nettingsmeier wrote:
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.
The problem is that AC Authoring, AC Trash, and AC Archive all allow
privilege escalation. There are two very large problems with this.
handing out the admin role is what allows privilege escalation.
i see what your problem is, and it surely needs to be solved in trunk.
but i'm still not convinced we should introduce fundamentally new role
semantics when all we need is a new usecase that allows users to grant a
configurable subset of roles.
ideally only those they own themselves (the WITH GRANT OPTION from SQL
land) - although this can also lead to escalation if two rogue
maintainers join forces, but we can ignore this threat imho.
1) It is quite advantageous to allow an admin to partition control over
AC Authoring out over parts of subtrees to individuals who may not be
admins fo the entire site. There is no way to do this without a fix. For
example go to Archive, then AC Archive with alice. From there (without
the patch) you could give yourself the admin role. After you have the
admin role, you can just click on ADMIN and away you go with full admin
rights.
2) If we don't want people to partition control over AC Authoring out to
other users we have a HUGE documentation nightmare. The real admins
obviously still need to get to AC Auth to partition out edit and review
roles. They have to be told to never ever ever ever under any
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
circumstances to grant someone the admin role.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
actually, i find this quite obvious, but you are right, our tree-based
roles easily make people expect otherwise. that is a documentation
issue. or else, all our ac usecases have to be made tree context
sensitive so that they behave as people would expect.
And why should I have to write a modified usecase to avoid the problem
when it's a core problem that EVERY deployment will have. I'm guessing
we want to deploy this to locations that don't have Lenya devs on staff.
So we need to fix this problem and it needs to be before 2.0.
agreed. i'm just not convinced it should be handled via new roles semantics.
I know I
don't have any say over the manner, but from my experience with Lenya
being deployed that's how I feel.
well, you have certainly as much say about this as yours truly. if
everyone else thinks this approach is ok, i'm accepting it. hell, it's
not as if i have tried to implement a really good solution myself yet,
so talk is cheap. i just feel we've been a bit too easy in the past with
introducing fundamentally new features to quickly solve the issue of the
day, and excuse my french but it has lead to a bloody fscking mess.
if despite my heckling everyone still thinks it's the approach to go
for, that's fine. i just want to make sure that everybody has considered
the implications of new role semantics vs. just writing a new usecase.
Andreas' patches are really quite minimal if you look at it. r597037
just makes it so that you can set roles that are not assignable. r597055
prevents circumvention of this by URL manipulation. They are a clean and
simple fix to the problem. However, they are such that any publication
already deployed will require some changes. Upgrading from 2.0 to 2.0.1
should be a simple matter.
I have not done large scale testing of the fix, but all of my testing
has been with the patch in place and have not found any issues.
as i said, if you still think it's appropriate, i'm trusting your
judgement. i don't have time atm to come up with something simpler, and
you obviously need this thing fixed, so go ahead.
--
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]
