PPS:
Just found a solution to question #1 myself (#2 is still open).
It should be possible to
- dump the old repository
- create a new repository with the more complex base structure and
permissions
- load the contents of the old one into a secure SUBfolder ("/secure")
that is only accessible by the admin
- move the secret files from "/secure" to their new locations
That should remove all evidence of the secret files on root (i.e.
public) level, but still preserve their history for those that need it.
(-> will the history be browseable from the new location?)
Daniel Kastenholz schrieb:
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jul 29 06:10:00 2006