> Greg Hudson <ghudson@MIT.EDU> writes:
>> On Wed, 2006-02-22 at 12:55 -0800, Garrett Rooney wrote:
>>> How would people feel about some mechanism for stopping update reports
>>> rooted at particular directories?
>> I think this is a good idea, as a safety measure. We just need to be
>> careful to document that it's purely a safety and not an access control;
>> a client could circumvent the mechanism by not using a report.
> If our authz system worked in a certain way, this could be done
> entirely through authz.
> Let ROOT be the root of the directory tree that you don't want
> checkouts to be rooted at. If you create an object ROOT/FORBIDDEN,
> and tell authz that no one is allowed to read or write FORBIDDEN, then
> what happens (today) if you check out ROOT? I believe you still get
> ROOT/*, with the exception of FORBIDDEN. However, if the authz system
> had a flag you could set to say "Don't allow an operation to happen at
> all if any part of it is not permitted", then the ROOT/FORBIDDEN thing
> would solve Garrett's problem.
The danger here is that you would not want to block normal browsing of
the repository just due to the fact you can not check out at root.
authz does not have fine grained access controls for things like checkout
vs get for example. Plus, many times I just do a diff between revision numbers
from "root" such that I don't need to remember a peg rev or what various
branches happened to have changes between here and there...
> The performance costs might be quite high, I haven't thought that
> through enough yet. I just wanted to try re-imagining this problem as
> a special case of authz, rather than as something special requiring
> new hooks or other new mechanism(s).
I would think that something that required full path checking each time
would be a bit high, but then a hook is also a bit high in the overhead
department. (Albeit not very high if it does not exist)
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:firstname.lastname@example.org
My place on the web http://www.sinz.org/Michael.Sinz
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Feb 24 04:42:22 2006