You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Robert Spier <rs...@pobox.com> on 2004/03/03 05:23:18 UTC
mod_authz_svn bug with multiple directories
I think I may have found a bug (or at least "user assumption failure")
in mod_authz_svn.
If a user has access to two directories, but not the parent directory,
(i.e.
[/test/level1/level2]
guest = rw
[/test/level1/level2a]
guest = rw
)
a commit to both of those two directories will result in a MERGE
request to the directory above. (/test/level1)
BUT - since the user can't write there, the MERGE result fails.
*kaboom*
-R
client: 0.33.0
server: 1.0.0
...
"svn-commit.3.tmp" 5L, 113C written
Authentication realm: <http://svn.mydomain:80> mydomain
Password for 'guest':
Sending level1/level2/red
Sending level1/level2a/fanta
Transmitting file data ..Authentication realm: <http://svn.mydomain:80> mydomain
Password for 'guest':
Authentication realm: <http://svn.mydomain:80> mydomain
Username: guest
Password for 'guest':
Authentication realm: <http://svn.mydomain:80> mydomain
Username: guest
Password for 'guest':
svn: Authorization failed
svn: Commit failed (details follow):
svn: MERGE request failed on '/test/test/level1'
svn: MERGE of '/test/test/level1': authorization failed (http://svn.mydomain)
svn: Your commit message was left in a temporary file:
svn: '/tmp/q/test/svn-commit.3.tmp'
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: mod_authz_svn bug with multiple directories
Posted by Robert Spier <rs...@pobox.com>.
> > One "real world" example of where this is going to bite us is when
> > we've given someone access to lib/Foo and tests/ - when they make a
> > change to lib/Foo, we also want them to make changes to tests/ and it
> > would be grrrrrrrrrreat if that could be one change.
>
> Quick workaround:
> <LimitExcept MERGE ...>
> SVNAuthzFile ...
> </LimitExcept>
Does this cause any security problems? Could someone easily craft a
malicious MERGE request?
-R
Footnotes:
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: mod_authz_svn bug with multiple directories
Posted by Sander Striker <st...@apache.org>.
On Wed, 2004-03-03 at 19:18, Robert Spier wrote:
> Right. But it might be interesting to do anyway... do we have any way
> of knowing that the MERGE was part of the same "session" as the PUT's?
> They're individual HTTP actions, so the answer may be "no" -- although
> even though the PUTs succeed, the MERGE fails, so the whole
> transaction is never recorded.. so the answer is probably yes. In
> that case, we can open it up only for the scope of the transaction,
> which probably is ok.
>
> One "real world" example of where this is going to bite us is when
> we've given someone access to lib/Foo and tests/ - when they make a
> change to lib/Foo, we also want them to make changes to tests/ and it
> would be grrrrrrrrrreat if that could be one change.
Quick workaround:
<LimitExcept MERGE ...>
SVNAuthzFile ...
</LimitExcept>
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: mod_authz_svn bug with multiple directories
Posted by Robert Spier <rs...@pobox.com>.
> > I think I may have found a bug (or at least "user assumption failure")
> > in mod_authz_svn.
>
> I'd classify it as a mix between 'pilot error' and bug. ;-)
60/40? 50/50? ;)
> > a commit to both of those two directories will result in a MERGE
> > request to the directory above. (/test/level1)
> > BUT - since the user can't write there, the MERGE result fails.
> >
> > *kaboom*
>
> Correct. To fix, guest would need rw on the parent directory as well.
> However, committing independently should resolve the problem. Does
> it?
Yes.
> I'm not sure what else we can do here. Perhaps we could build in some logic
> that if someone can write to a child directory, MERGE should then succeed?
> (i.e. an implicit w permission to call MERGE.) Although I think that might
> open us up a bit too much. -- justin
Right. But it might be interesting to do anyway... do we have any way
of knowing that the MERGE was part of the same "session" as the PUT's?
They're individual HTTP actions, so the answer may be "no" -- although
even though the PUTs succeed, the MERGE fails, so the whole
transaction is never recorded.. so the answer is probably yes. In
that case, we can open it up only for the scope of the transaction,
which probably is ok.
One "real world" example of where this is going to bite us is when
we've given someone access to lib/Foo and tests/ - when they make a
change to lib/Foo, we also want them to make changes to tests/ and it
would be grrrrrrrrrreat if that could be one change.
-R
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: mod_authz_svn bug with multiple directories
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Tuesday, March 2, 2004 9:23 PM -0800 Robert Spier <rs...@pobox.com>
wrote:
> I think I may have found a bug (or at least "user assumption failure")
> in mod_authz_svn.
I'd classify it as a mix between 'pilot error' and bug. ;-)
> If a user has access to two directories, but not the parent directory,
>
> (i.e.
> [/test/level1/level2]
> guest = rw
> [/test/level1/level2a]
> guest = rw
> )
>
> a commit to both of those two directories will result in a MERGE
> request to the directory above. (/test/level1)
>
> BUT - since the user can't write there, the MERGE result fails.
>
> *kaboom*
Correct. To fix, guest would need rw on the parent directory as well.
However, committing independently should resolve the problem. Does it?
I'm not sure what else we can do here. Perhaps we could build in some logic
that if someone can write to a child directory, MERGE should then succeed?
(i.e. an implicit w permission to call MERGE.) Although I think that might
open us up a bit too much. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org