Alec Thomas wrote:
Well, the minimal security sandbox is largely complete. I've added
fine-grained permissions to most parts of Trac that made sense (ie.
mostly where they already existed).
I'd like to get some feedback on whether you think this is a good
initial approach. I think it is, mainly because it's backward
compatible with almost zero impact, while still providing a high degree
of control over access to resources.
More discussion here:
http://projects.edgewall.com/trac/wiki/PermissionPolicy
I added some links in that page to help for reviewing the code (*)
I haven't make use of those features, and I don't think I'll need them
anytime soon, however I think the approach is sound and flexible enough
for most of the security concerns already expressed so far, in particular
the privacy concerns for tickets that would relate to security issues
(e.g. from the example you provided, one clearly see how to write a policy
for making a '[security]' ticket accessible only to developers and to
the original
authenticated author, until the ticket is made public).
I also acknowledge that by using the IResourceIdentifier you provide
a framework which is not only more general than using only TracObjects
but which can easily take benefit of the TracObjects once they become used
(one IResourceIdentifier to identify them all :) ).
I'll reiterate what I already said earlier, I don't see any need to
post-pone
this to 0.11, as the changes are low risk. I'd vote for the inclusion of
this now.
-- Christian
(*) As a side note, this shows that you missed one revision during the
merge from trunk, namely r3177.
This is a "boundary" problem, I think: in r3191, you state that you did
a merge of the [3177:3190]
range, but for that you certainly used a command like 'svn merge
-r3177:3190 <trunk> <security>'
It should have been 'svn merge -r3176:3190 ...' in order to contain the
r3177 changes as well.
_______________________________________________
Trac-dev mailing list
[email protected]
http://lists.edgewall.com/mailman/listinfo/trac-dev
