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

Re: How to best manage authorization after tag/branch creation?

From: BRM <bm_witness_at_yahoo.com>
Date: Wed, 13 Oct 2010 12:59:18 -0700 (PDT)

----- Original Message ----

> From: Shaun Pinney <shaun.pinney_at_bil.konicaminolta.us>
> > The usual issue is making sure people outside the project are
> > prevented from reading the code. You might not want people in your
> > project making changes on tags and branches, but there usually isn't a
> > security issue if they see the code on the branches and tags.
> Our issue is handling multiple companies doing development on the same
> project. Various restrictions (e.g. licensing) prevent us from sharing
> all project files with everyone involved. It's a tricky use case. We
> also have additional considerations which require us to control project
> read access within a project even within the same company.
> > The only way you can prevent people from reading your code is to setup
> > httpd configuration. pre-commit hooks can't do this and there's no
> > pre-checkout hook.
> Yeah, was afraid of that...

I've always been an advocate of the Apache2+WebDAV setup for SVN.
It's just easier.

I know the apache access method (webdav) has path-based authentication;
I don't know about the others.

If you need to control access to the code you can do things such as:
- only allow the developers that need access access to the whole project
- setup a secondary tags namespace for special binary only information
- have the build mechanism push the binaries to a special binary tag by the same
name
- use svn:externals to reference the binary releases instead of source releases.
 
> > However, changing httpd configuration is tricky since it involves
> > having root access on the httpd server and being able to at least
> > bounce the server when the permissions get changed.
>
> Yes. Perhaps if there was a pre-checkout hook it'd be possible to create
> a homegrown admin tool. Or perhaps if Subversion had a feature to natively
> manage access control within a repository then no Apache changes would be
> needed in the first place. Either way, some automation would be useful here
> but it may not be possible to implement.
>
> > >> By the way, there's also a way to configure Apache httpd to use LDAP
> > >> instead of a regular text file. This means that users will have access
> > >> to your Subversion repository based upon their Windows or Unix account
> > >> and that users will automatically get logins and have their access
> > >> removed when they get hired or move on.
> > >
> > > That's something we'll definitely consider. We have some other quirks
> > > with account management to sort out first :)
> >
> > When your development team gets bigger than a dozen people, you start
> > having people come and go all the time. That makes it difficult to
> > keep the httpd configuration up to date. It just becomes easier if
> > this becomes more automated. Or at least someone else's problem when a
> > new developer doesn't have access to Subversion.
>
> I completely agree, and will be using that argument to push for it (or
> at least the first part :)

And that's why you use LDAP or another alternative authentication method.
BTW, Subversion does support groups as part of the path-based authentication.
I don't know how that interacts with LDAP if at all, but that might be something
to investigate or perhaps add support for.

$0.02

Ben
Received on 2010-10-13 21:59:57 CEST

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.