Hi,
I have a question regarding the fundamental security concept behind
authorizations in Subversion.
The situation is that I have now a repository that grants r/w access to
all team members, but due to a team enlargement, I need to hide certain
documents from new members. I'm now trying to find out how to accomplish
this. My first idea was this:
Assume I have a repository structure like this in Revision 100:
/
/folder
/secret-A
/secret-B
Now I figure out that some better not access A and others shouldn't
access B. So in revision 150 I change the structure as follows, say, by
moving the files:
/
/folder-1
/secrets
/group-1
/secret-A
/group-2
/secret-B
Then I define the authorization table as follows (which seems the only
way to ensure that everybody can access their resources):
[/]
*=r
[/folder-1/secrets/group1]
*=
@group1 = rw
[/folder-2/secrets/group2]
*=
@group2 = rw
Question 1:
what would prevent anyone from going back to revision 100 and reading
the contents even without permissions!?
Question 2:
correct me if I'm wrong, but Subversion's entire security system seems
to be blacklist-based to me, i.e. I first have to grant access to
everybody on everythig and then restrict access for those resources that
I don't want certain people to see. But isn't that exactly the approach
that should be avoided in every security-related environment (firewalls,
filesystems, etc.)?! Wouldn't it need a whitelist-oriented approach to
make the authorization system waterproof?
Actually, the root cause of the problem seems to have to do with how
Subversion treats the parent folders in authorization declarations.
Linux, for instance, allow users to jump into a deep subfolder even if
they do NOT have read permissions on the parent folders. Subversion
seems to lack this functionality.
Take
[/folder-1/secrets/group1]
@group1=rw
For this declaration to work, it appears that I also need to grant
access to "/folder-1" and "/folder-1/secrets" before group1 can actually
access the resource. But that's insane, as it would also grant access to
everything EXCEPT the resource to group-1 if nothing else is stated. And
now assume that somebody forgot to explicitly protect a critical
resource, or probably made a typo or renamed that critical resource
without updating the authorization file. Result: security hole.
Or am I just panicking?!
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jul 29 05:39:37 2006