subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From BRM <bm_witn...@yahoo.com>
Subject Re: How to best manage authorization after tag/branch creation?
Date Wed, 13 Oct 2010 19:59:18 GMT
----- Original Message ----

> From: Shaun Pinney <shaun.pinney@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


Mime
View raw message