access control in Subversion

[Dimitri Papadopoulos-Orfanos <pa...@shfj.cea.fr>]

Hi,

We're considering moving from Perforce to Subversion and I'm trying to 
decide how to configure Subversion at our site with respect to access 
control.

* We need closed source files to be readable only by a group A of 
authentified and authorized persons.

* We need closed source files to be writable only by a group B of 
authentified and authorized persons.

* We need open source files to be readable for anyone, even in the 
absence of athentication.

* We need open source files to be writable only by a group C of 
authentified and authorized persons.

* Groups A, B, and C are different, and we could actually have more 
complex situations where different groups of developers work on 
different projects. For example we could define groups A1 and B1 for 
project 1 and A2 and B2 for project 2, all of them being different.


I guess other people on this list have similar requirements. Which 
solution would you suggest? Is there a HOWTO?


Obviously the built-in authentication and authorization model won't do. 
 From the book:
	Notice that svnserve only understands "blanket" access control.
	A user either has universal read/write access, universal read
	access, or no access. There is no detailed control over access
	to specific paths within the repository. For many projects and
	sites, this level of access control is more than adequate.
	However, if you need per-directory access control, you'll need
	to use Apache instead of svnserve as your server process.

Apache is not a solution locally, for reasons beyond my reach. We just 
cannot install and run a Web server, no matter what it's used for - it 
would mean too much efforts to get an authorization for that. Also I'm 
not sure it's possible to require authentication for writing a file but 
not for reading it. Finally it's too much hassle to install so many 
different packages on the server and Apache access appears to be 
significantly slower.

The only remaining solutions are svn+ssh (for authentified users) and 
svn (for read access without authentication). The problem here is that 
traditional POSIX file permissions are not expressive enough in our 
case. It seems we need ACLs. ACLs are not supported by our backup system 
by the way, but that's another problem. I've read "Supporting Multiple 
Repository Access Methods" but I still think we need both svn+ssh and 
svn access. Any thoughts on that? Any tips? Any HOWTOs about chossing 
users and groups, setting ACLs and umasks?

Regards,
--
Dimitri Papadopoulos

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: access control in Subversion

[Dimitri Papadopoulos-Orfanos <pa...@shfj.cea.fr>]

Hi,

> seems that your company's policies have painted you in a bit of a corner. the 
> authorization authz module for apache will do exactly this.  i don't have any 
> idea what you have in mind for "write only" users though.  blindfolds?

We actually don't have "write only" users. An additional rule was 
probably missing: Files that can be written by a group/person can also 
be read by the same group/person.

As for Apache, apart from the administrative hassle it would mean for 
me, I wish to depend on as few external packages as possible, because 
that increases the possibility something goes wrong during OS upgrades 
(Subversion already relies on BD, I'd rather not add Apache). Also does 
Apache allow to read a file without authentication and require 
authentication for writing it?

> it sounds to me like it may be a lot easier to get your dark overlords to 
> authorize the purchase of a commercial sccm.  then again, they seem to not be 
> bothered by keeping you from getting any work done.

We already have Perforce. However purchasing and upgrading licenses is 
hell: my organisation usually deal with local resellers but Perforce 
have no local resellers. For the lack of a local reseller everything 
that can go wrong will go wrong when upgrading licenses (and that's 
probably not Perforce's fault). I just want to avoid that and was 
therefore thinking of moving to Subversion.

Otherwise I have to agree there are many constraints here - but I can't 
address and change them all. On the other hand, facilitating my own work 
is not the unique goal of my organisation. There are other issues to 
take into account, such as security issues that may be addressed by 
organisation-wide policies. Organisation-wide policies tend to get in 
the way of part of the people in an organisation; some policies are 
better, some of them are more flexible, and some of them harm lots of 
people in the organisation.

Regards,
--
Dimitri Papadopoulos

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: access control in Subversion

[McClain Looney <m...@loonsoft.com>]

seems that your company's policies have painted you in a bit of a corner. the 
authorization authz module for apache will do exactly this.  i don't have any 
idea what you have in mind for "write only" users though.  blindfolds?

it sounds to me like it may be a lot easier to get your dark overlords to 
authorize the purchase of a commercial sccm.  then again, they seem to not be 
bothered by keeping you from getting any work done.


On Tuesday 16 March 2004 09:03 am, Dimitri Papadopoulos-Orfanos wrote:
> Apache is not a solution locally, for reasons beyond my reach. We just
> cannot install and run a Web server, no matter what it's used for

-- 
McClain Looney
LoonSoft LLC
m@loonsoft.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org