Michael Sinz wrote:
>> Is there a compelling reason to prevent a partial-access-granted user from
>> changing the two properties he's allowed to see?
>
> I wonder if this is correct. Just because you can see part of the commit
> information, does that mean it is safe or correct to be able to change it?
See, this is where things devolve into a matter of definitions. When you
phrase it like "Just because you can see part of the commit information...",
then yeah, it feels like the status quo is correct. But you can also phrase
it like "Just because you can see a particular revision property...", at
which point we're not talking about someone undermining the whole of
something by virtue of access to a small part of it.
So part of the question I'm asking is, is The Revision Metadata (meaning the
changed-paths list and all properties on the revision) a "whole" that needs
protecting in this way? I lean towards, "no". Why? Because our whole
security model is path-based (not revision-based), and the only reason we
have to muck with this whole weird staged revision access thing is because
in Subversion, multiple changed paths are bound to a single revision with a
single log message and single author and single date. Had we a CVS-like
model with per-path log messages, we wouldn't even be having this
discussion. The only reason, IMO, that we even talk about this state as
"partial revision access" is for convenience -- it's much easier to say that
than to say the user has "read access on some of the changed paths in the
revision and two of the revision properties".
Also, I can't conceive of any real harm in letting someone tweak the author
or date of a partially-accessible revision. Okay, maybe if there's some
custom script in place that emails committers weekly the full log messages
of all the commits they made that week ("Subject: What You Did Last Week"),
this would let someone claim a revision that wasn't his and possibly see
privileged svn:log information when that email hits. But I think that's a
stretch.
> PS - even in the repositories where we have this tight security, I have not
> seen even one commit that crosses boundaries. This is, most likely, due to
> the fact that very few people have rights across boundaries, but even those
> that do have never caused such a commit.
And this is what I suspect is true for most folks. (But thanks for the data
point.)
By the way, I don't feel actually feel very strongly about any of this. My
agenda is simple: (re)determine the policy, and (most importantly)
*document it and its reasons in the notes/ directory*.
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Mon May 21 15:34:55 2007