subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Schmidt <>
Subject Re: File access control
Date Sun, 02 Oct 2011 01:51:03 GMT

On Oct 1, 2011, at 20:07, Grant wrote:

>> There is a repository -- a database -- that holds your code. The current version
and all past versions, including, if you like, branches. This could be on any server you like
-- the production server, the development server, a completely separate server -- doesn't
really matter. That server will run some kind of Subversion server software -- svnserve perhaps,
or Apache 2 with mod_dav_svn.
>> Anyone who works on the code will check out a working copy from the repository onto
their work machine. They will modify the code, then they will test the changes on their local
work machine (which in your case means they will be running a web server and whatever else
necessary to run the web site on their work machine). Once satisfied the changes are correct,
they'll commit the changes back to the repository, with a message describing what they did.
> Ouch.  If testing is done on the developer's local machine, he will
> need a full working copy and it will be impossible to restrict read
> access to one or a few files as I had planned to do with path-based
> authz.  Instead, could I check out a working copy of the repository to
> a staging machine of mine and allow the developer to check out only
> one or a few files as defined via path-based authz, thereby requiring
> him to commit his changes and update the staging machine's working
> copy in order to test his changes and debug?  I suppose each developer
> would require a separate staging machine to work this way.
> I'm really getting the square peg round hole feeling.  The workflow
> you describe is elegant and very enticing but it gives all of my code
> away.  The prevailing attitude seems to be that developers should be
> trusted, but this goes against everything I've learned about system
> administration where security is taken seriously and trust doesn't cut
> it.  I could go the NDA/NCC route but that seems only slightly more
> secure than trust to me.
> All of the big enterprise websites allow each of their developers to
> check out a full working copy of the company code with only an NDA/NCC
> to protect them?  It would be so easy for any of them to use, sell, or
> give the code away, or even to accidentally allow an unauthorized
> person access to it.

You're right, your restriction of not wanting to give the developer access to all the files
needed to make the web site function does complicate matters. It's a situation I didn't have
to deal with in the web development shop where I worked. We didn't use authz; everyone had
access to everything.

Usually, you want to test your work before you commit it. But in your case you might adopt
a different policy, of allowing people to commit work, in order to then test it on a central
development server. The development server could have a full working copy of the site, and
could be configured with a post-commit hook to automatically update itself after every commit:

Nobody would have permission to modify that working copy in any way; only the server itself
would have the ability to update it, by running "svn update". This ensures it's a pristine
copy of what's in the repository.

You could grant your untrusted developers access to relevant parts of the repository using
authz, which they would check out to their local machines, modify, commit, and then access
your dev server's central URL to see if their changes worked. If not, they'd make another
change and commit, until things worked.

Instead of having this developer modify the trunk, you might give them access to a special
branch of the code. This way their changes are isolated from your trusted developers, or even
from other untrusted developers. Somebody trusted then takes on the task of merging their
work into the trunk when it's done.

In this scenario, you might indeed set up a separate virtual host (separate instance of the
app, separate dev server working copy) for each such branch. No need for there to be separate
servers though.

View raw message