C. Michael Pilato wrote:
> 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.
This is more a conceptual question than a "real harm" question. One of the
things that makes SVN *oh so much better than* CVS is the atomic commit.
To me, this means that the commit is treated as a whole unit. Thus, if
you start talking about parts of the commit/log message/etc not being
accessible we already get into a strange state of "you get a small part of it"
type of rule.
The question then becomes - should I be able to change a revprop on a revision
where I don't know the whole story? That is, what is the correct operation if,
for example, I have only rights to part of the tree in a revision? Since the
revision is atomic, why should I be able to change a revprop for something that
is partially off-limits to me? If the revision was somehow split into the
part I could see and the part I can't (say, as two different commits) then I
could change the revprop of the part I can see and can't change the revprop
of the part I can't. However, once they are tied together, why would I assume
to be able to change a revprop that has a direct relationship to a part I can
not see?
>> 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*.
I too am not too invested in this other than my security and audit hat keeps
showing up... That is part of why I jumped into this discussion in the first
place.
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:michael.sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 22 06:34:50 2007