You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "C. Michael Pilato" <cm...@collab.net> on 2007/05/18 20:09:04 UTC
Is our revprop auth policy too strict?
Back when we introduced the idea of authorization policies for revision
metadata, we designed things such that a given user could have "full",
"partial", or "no" access to a given revision's metadata. The determination
of these access levels is based entirely on the paths affected as part of
the revision:
* "full" access is granted when there is no such path the user
can't read.
* "no" access is granted when there is no such path the user
can read.
* "partial" access is granted when there's at least one path
the user can read, and at least one he can't.
How do these policies affect what the user sees?
Well, in all cases, the user only gets to see the paths he can read. But
the policy affects revision properties, too. "No" access, no properties.
"Full" access, all properties. "Partial" is the oddball -- you only get to
see the svn:author and svn:date properties (because the log message and
custom properties might contain text that mentions the priveleged paths).
I think those are all quite fine as policies go, and I'm not proposing a
lick of change there. (If others wish to do so, please use a different thread.)
But I noticed the other day that when it comes to *write* access for
revision properties, "full" and "no" access do what you'd expect, but
"partial" is treated just like "no" access -- in other words, the user can
read svn:author and svn:date, but can't change them. That seemed odd to me
(and to sussman, when I raise the question elsewhere).
Is there a compelling reason to prevent a partial-access-granted user from
changing the two properties he's allowed to see?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Is our revprop auth policy too strict?
Posted by Garance A Drosihn <dr...@rpi.edu>.
At 2:18 PM -0400 5/21/07, C. Michael Pilato wrote:
>Garance A Drosihn wrote:
>> At 6:05 AM -0400 5/21/07, Michael Sinz wrote:
>>>
>>> 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?
>>> Given that the user can not access all of the commit information, I would
>>> think it is improper to allow changes to even those values that can be
>>> seen.
>>> After all, it may be very incorrect.
>>
>> As I understand it, the debate is what behavior subversion should allow
>> by default. I think it makes the most sense to leave the default as it
>> is, because the owner of any repository can provide wider access if they
>> believe that is appropriate.
>
>That's not as true as you might like to think.
>
>With the current behavior, the way an owner of a repository provides wider
>access to a user's ability to tweak, say, the svn:date property, would be to
>grant him/her read access to all the paths changed in the revision. If
>you're scratching your head and wondering, "Why in the world would the admin
>have to grant path access just to let someone change a revision property?",
>then you're at the same place my head is. (Welcome. Nice to have you.) :-)
Hmm. I'm probably missing some detail here. I've setup some repos
so a specific account change change svn:date properties, but that
account already had write access to the entire repo, so I probably
haven't run into the issue that's being discussed here.
It did seem like I was missing a message or two in this thread, but I
thought I had a pretty good idea of what the question was based on the
others. But it sounds like I ended up a bit off-track. Sorry about
that!
--
Garance Alistair Drosehn = gad@gilead.netel.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Is our revprop auth policy too strict?
Posted by "C. Michael Pilato" <cm...@collab.net>.
Garance A Drosihn wrote:
> At 6:05 AM -0400 5/21/07, Michael Sinz wrote:
>>
>> 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?
>> Given that the user can not access all of the commit information, I would
>> think it is improper to allow changes to even those values that can be
>> seen.
>> After all, it may be very incorrect.
>
> As I understand it, the debate is what behavior subversion should allow
> by default. I think it makes the most sense to leave the default as it
> is, because the owner of any repository can provide wider access if they
> believe that is appropriate.
That's not as true as you might like to think.
With the current behavior, the way an owner of a repository provides wider
access to a user's ability to tweak, say, the svn:date property, would be to
grant him/her read access to all the paths changed in the revision. If
you're scratching your head and wondering, "Why in the world would the admin
have to grant path access just to let someone change a revision property?",
then you're at the same place my head is. (Welcome. Nice to have you.) :-)
> If the default behavior of svn is changed such that committers have
> write-access to all revision properties, then they can change those
> properties in whatever way they want, and the admin of the repo may
> never realize that it's happening. Given that the revision-properties
> are not versioned, I personally think this is a bad thing.
I agree. And fortunately, that scenario isn't even close to what's being
proposed here.
Subversion's default behavior is to disallow revprop changes entirely.
That's definitely the safest default given the fact that revprops aren't
versioned, and is not up for debate. This thread is about something much
more specific than "all committers" or "all revprops", though. I think
you've missed some (all?) of the key portions of the discussion here.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Is our revprop auth policy too strict?
Posted by Garance A Drosihn <dr...@rpi.edu>.
At 6:05 AM -0400 5/21/07, Michael Sinz wrote:
>
>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?
>Given that the user can not access all of the commit information, I would
>think it is improper to allow changes to even those values that can be seen.
>After all, it may be very incorrect.
As I understand it, the debate is what behavior subversion should allow
by default. I think it makes the most sense to leave the default as it
is, because the owner of any repository can provide wider access if they
believe that is appropriate.
Remember that revision properties are not themselves versioned, so if
some user changes a revision property, then there is no way of knowing
what the original ("correct") value was.
If you have a repository with a lot of committers, and if they really
should have access to the revision properties, then they can go to the
admin of that repo and say "Hey, I need access". Thus the admin will
make the explicit decision whether they want committers to have write
access to the revision properties.
If the default behavior of svn is changed such that committers have
write-access to all revision properties, then they can change those
properties in whatever way they want, and the admin of the repo may
never realize that it's happening. Given that the revision-properties
are not versioned, I personally think this is a bad thing.
>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.
If everyone has access to revision-properties, then I think they'll be
more inclined to make changes, and more likely to make changes which
are mistakes. Really, if 95% of your committers have no ability to
modify the revision properties, then you cannot consider it significant
that they haven't made an inappropriate change. Even the 5% who do
have access will realize that these are important properties that
they shouldn't be changing on a whim, and thus they will be more
careful about what they do with them.
And if you are only giving access to a few developers, then which
developers are you giving access to? The senior developers who have
already proved themselves, or the junior hot-shot freshman college
student developers who think they know everything about programming,
but in fact know nothing about working as part of a large group of
programmers?
The whole idea of a repository is to accurately track the history of
a given project. You give people commit access, because even if they
totally screwup the commit, you can always find out what the state of
the project was before the mistake was committed. As long as revision
properties are not versioned, then a mistake made when changing a
property will forever lose some small detail of history for the project.
--
Garance Alistair Drosehn = gad@gilead.netel.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Is our revprop auth policy too strict?
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Mon, May 21, 2007 at 10:22:15AM -0400, C. Michael Pilato wrote:
> > Given that we already have revprop change hooks, aren't you actually
> > asking: "should Subversion force a read-only policy for the partial
> > access case"? And given that, I'd say the answer is emphatically not:
> > there are some policies that are worth enforcing in the core, but this
> > doesn't seem like one of them - let the hook dictate the policy, it's
> > what it's there for.
>
> Sorry to be annoying, but are you advocating a staged write access in the
> core that matches our staged read access -- the "if you can see it, you can
> change it" policy? Or are you saying we should leave all write-blocking to
> the hooks?
>
Heh. I'm saying we should go for the former ("iif you can see it, you
can change it"). You're right that my position also suggests the
latter, though I'll handwave away the contradiction by pointing out that
because we already enforce read policy in the core, it's better for
consistency to use the same logic to enforce write policy than to say
"oh, we already have a general write policy mechanism, let's use that
for writes, but enforce policy for reads ourselves".
Best of all might (_might_) be to delegate both read- and write-policy
down to hooks and drop all notion of policy in the core completely,
though that might be too complex to bother with (really, how common are
partial-access commits?).
> Oh, I've already got a patch ready for commit that does the easy-detection
> (for scripts that use the APIs/bindings. :-) That's no sweat.
>
Ex-cellent :-)
Regards,
Malcolm
Re: Is our revprop auth policy too strict?
Posted by "C. Michael Pilato" <cm...@collab.net>.
Malcolm Rowe wrote:
> On Mon, May 21, 2007 at 09:34:45AM -0400, C. Michael Pilato wrote:
>> 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.
>>
>
> You're right, that seems unlikely.
>
> Given that we already have revprop change hooks, aren't you actually
> asking: "should Subversion force a read-only policy for the partial
> access case"? And given that, I'd say the answer is emphatically not:
> there are some policies that are worth enforcing in the core, but this
> doesn't seem like one of them - let the hook dictate the policy, it's
> what it's there for.
Sorry to be annoying, but are you advocating a staged write access in the
core that matches our staged read access -- the "if you can see it, you can
change it" policy? Or are you saying we should leave all write-blocking to
the hooks?
> (Now, if you want to make a case that the hook should have an easy way
> to _detect_ this partial-access case, I completely agree, but that's a
> different discussion...)
Oh, I've already got a patch ready for commit that does the easy-detection
(for scripts that use the APIs/bindings. :-) That's no sweat.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Is our revprop auth policy too strict?
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Mon, May 21, 2007 at 09:34:45AM -0400, C. Michael Pilato wrote:
> 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.
>
You're right, that seems unlikely.
Given that we already have revprop change hooks, aren't you actually
asking: "should Subversion force a read-only policy for the partial
access case"? And given that, I'd say the answer is emphatically not:
there are some policies that are worth enforcing in the core, but this
doesn't seem like one of them - let the hook dictate the policy, it's
what it's there for.
(Now, if you want to make a case that the hook should have an easy way
to _detect_ this partial-access case, I completely agree, but that's a
different discussion...)
Regards,
Malcolm
Re: Is our revprop auth policy too strict?
Posted by Michael Sinz <Mi...@sinz.org>.
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
Re: Is our revprop auth policy too strict?
Posted by "C. Michael Pilato" <cm...@collab.net>.
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 <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Is our revprop auth policy too strict?
Posted by Michael Sinz <Mi...@sinz.org>.
Malcolm Rowe wrote:
> On Fri, May 18, 2007 at 04:09:04PM -0400, C. Michael Pilato wrote:
>> "partial" is treated just like "no" access -- in other words, the user can
>> read svn:author and svn:date, but can't change them. That seemed odd to me
>> (and to sussman, when I raise the question elsewhere).
>>
>> Is there a compelling reason to prevent a partial-access-granted user from
>> changing the two properties he's allowed to see?
>>
>
> Not that I can think of. +1 for symmetry.
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?
Given that the user can not access all of the commit information, I would
think it is improper to allow changes to even those values that can be seen.
After all, it may be very incorrect.
I would say that if you are doing this tight level of access control then
that a revision that a use does not have access to all elements of it should
be "read-only" by definition.
At least that is how I see this. I can not come up with a scenario where
someone who does not have rights to all of the revision should have any reason
or rights to change any part of the revprop - even those that they can 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.
--
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
Re: Is our revprop auth policy too strict?
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Fri, May 18, 2007 at 04:09:04PM -0400, C. Michael Pilato wrote:
> "partial" is treated just like "no" access -- in other words, the user can
> read svn:author and svn:date, but can't change them. That seemed odd to me
> (and to sussman, when I raise the question elsewhere).
>
> Is there a compelling reason to prevent a partial-access-granted user from
> changing the two properties he's allowed to see?
>
Not that I can think of. +1 for symmetry.
Regards,
Malcolm