Path based authz - problem with rules for moved/deleted content

["Schmidt, Michael" <Mi...@mevis.fraunhofer.de>]

Hello,

In my research institute we are using SVN with path based access control via mod_svn_authz. Now I am facing the problem that we had some code within our trunk folder which is only accessible to a subgroup of developers. In order to protect it from unauthorized access we added an access restriction for that code. Unfortunately, we learned the hard way that this is not really a good thing to do since it prevents all other users from being able to branch the trunk folder. Obviously, even after moving the "confidential" code to a different location we still have to keep the old authz rules in place in order to prevent leaking the code to unauthorized developers through the history access. Unfortunately, the existence of these rules continues to prevent non-privileged developers rules from being allowed to copy the trunk, although no content in the trunk is actually matched by the rules anymore. Currently, the only solution to this problem that I see would be to move the (now cleaned) trunk to a new location for which no such conflicting rules exist. However, we would rather use this as a last resort and prefer a solution that let's us continue to use the current structure. This is especially true since it could happen that somebody again commits confidential information to the trunk which then needs to be protected when we notice it.

Is anybody aware of a good way to deal with this kind of issues? Or is there any development going on to support such things in future versions, e.g. by allowing to configure revision ranges for which rules apply? I would appreciate any helpful hints on how one could deal with this topic now or in foreseeable future.

Best regards, Michael


------------------------------------------
Michael Schmidt
Fraunhofer MEVIS
Institute for Medical Image Computing
Universitaetsallee 29
28359 Bremen

Phone: +49-421-218-59273
Fax:   +49-421-218-98-59273

Email: michael.schmidt@mevis.fraunhofer.de<ma...@mevis.fraunhofer.de>
Web:   http://www.mevis.fraunhofer.de
------------------------------------------

Re: Path based authz - problem with rules for moved/deleted content

[Branko Čibej <br...@wandisco.com>]

On 13.02.2013 10:30, Schmidt, Michael wrote:
>
> Hello,
>
>  
>
> In my research institute we are using SVN with path based access
> control via mod_svn_authz. Now I am facing the problem that we had
> some code within our trunk folder which is only accessible to a
> subgroup of developers. In order to protect it from unauthorized
> access we added an access restriction for that code. Unfortunately, we
> learned the hard way that this is not really a good thing to do since
> it prevents all other users from being able to branch the trunk
> folder. Obviously, even after moving the “confidential” code to a
> different location we still have to keep the old authz rules in place
> in order to prevent leaking the code to unauthorized developers
> through the history access. Unfortunately, the existence of these
> rules continues to prevent non-privileged developers rules from being
> allowed to copy the trunk, although no content in the trunk is
> actually matched by the rules anymore. Currently, the only solution to
> this problem that I see would be to move the (now cleaned) trunk to a
> new location for which no such conflicting rules exist. However, we
> would rather use this as a last resort and prefer a solution that
> let’s us continue to use the current structure. This is especially
> true since it could happen that somebody again commits confidential
> information to the trunk which then needs to be protected when we
> notice it.
>
>  
>
> Is anybody aware of a good way to deal with this kind of issues? Or is
> there any development going on to support such things in future
> versions, e.g. by allowing to configure revision ranges for which
> rules apply? I would appreciate any helpful hints on how one could
> deal with this topic now or in foreseeable future.
>

There's a long-standing idea for implementing access control in the
repository itself, i.e., not relying on an external access configuration
file. Applying ACLs to certain (historical) revision ranges is part of
that idea.

I can't promise anything about when it'll be available, but some of us
are hoping to at least write a design for that in the near future.

-- Brane


-- 
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com