[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Queries about SVN (Security related)

From: Nico Kadel-Garcia <nkadel_at_gmail.com>
Date: Fri, 25 Nov 2011 09:47:50 -0600

On Fri, Nov 25, 2011 at 3:57 AM, Cooke, Mark <mark.cooke_at_siemens.com> wrote:
> [Please reply in-line, it makes it easier to see the full context...]

>> > Dear Sir,
>> >
>> > We are in the process of selecting SVN system in our company,
>> > could you please clarify following points.
>> >
>> > 1. Restricting branching activity based on roles specified.
>> >    That is denying branch functionality to users based on
>> >    their roles.
>> > 2. Denying delete/add folder to certain users, it is not just
>> >    r or r/w. if user has r/w access but shouldn't have delete or
>> >    add access, only modify commit should be accessible.
>> This functionality is not "baked in".  It might well be
>> possible to do with a pre-commit hook but you (your admin
>> team) would need to write and maintain the script.
>> Personally I have not tried to do such things.

Amen. Pre-commit scripting is extremely powerful and flexible, because
it supports whatever a scripting language can do. But let's be clear.
If they have "modify" access, they have "delete" access, at least with
the scripting and authorization structures I've seen.

"Create" access is a bit different: there are setups that allow
creating tags, for example, but not deleting them.

You also want to think very hard about what kind of access you
provide, and what kind of layout you use. Apache access allows access
control through normal Apache configurations, which can be quite
sophisticated, but presents the old (and much lamented by me) problem
that the UNIX and Linux Subversion clients store their passwords in
clear text, by default, for http:// or https:// access. It's why I
insiste on svn+ssh access, and that has different tools for
controlling access based on the svnserve configuration.

Workflow will also matter tomake it usable. Will people work in one
large repository with lots of branches and distinct projects, each
with their own branches and trunks and tags? This is common, and may
be easier to manage, but means one authorization and access setup to
manage and to screw up. If it's chaning all the time, it's easy to cut
off *everyone's* access with one typo, and there aren't currently
GUI's or sophisticated editing tools for managing this, so use caution
before getting too cute.

>> > > 3. Is it possible host repos in 2 different physical locations?
>> >
>> > What do you mean by host?  There is built-in support for
>> > providing read-only mirrors (also as write-through proxies)
>> > but if you want multiple 'master' repositories then you need
>> > to look to WanDISCO's proprietry MultiSite extension.
>> >
>> I meant in Collabnet admin GUI we can give location of only
>> one data location, i.e., if we want to place repos in more
>> than one machine or physical location, is it possible.
> Do you mean separate repositories?  That is down to how you configure apache.  I have not used the Collabnet admin GUI having decided at the start that I wanted to understand what was going on.  You can easily declare multiple SVNParentPath locations (I do this for hosting separate groups of projects) within the one apache config.  However, AFAIK you need the data files on storage "local" to the server (networked storage does not seem to be recommended).  I use a virtualised windoze server box with virtual local disk space but we have modest storage requirements so far.

There's also the more sophisticated tools of WanDisco's commercial
grade "multi-home" setup, designed to keep multiple repositories
synchronized and available for failover behavior. Interesting stuff
that I've not had the money and personal requirement for, but it might
serve for this.

>> > 4. How to delete folders or file permanently.
>> I assume you mean "remove completely from all history"?
>> Ignoring all the arguments about if a source control product
>> should even allow this, it is only currently possible by
>> 'dump', 'dumpfilter' and 'reload'ing the whole repository.
>> It is a feature on the roadmap
>> (http://subversion.apache.org/roadmap.html) called
>> 'obliterate' but not soon.

Yes, "obliterate". Its absence is a long-standing problem: Once
someone stores an inappropriate and bulky DVD image, or a file with
confidential information in it, it's an extremely awkward and fragile
and manual process to remove it. The easiest way is usually to
transfer the data to a new repository with the old data excluded, and
switch everyone to use the new repository. This can cause real
problems with ongoing work, but it works.

Note that the idea that a source control should *never* eliminate all
traces of its history is understandable. It used to be too easy to
completely screw up a CVS repository with a casual deletion of a
particular file, and Subversion is sometimes referred to as "CVS done
right", so the historical resistance to such a feature is
understandable. It's very dangerous and could delete exactly the
change history you need badly to figure out when something got screwed
up and by whom, so it should be used cautiously.
Received on 2011-11-25 16:48:22 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.