> is it possible to use system accounts with svn[serve]?
> /svnroot/repos* has some repositories.. where folders are owned by
> different system groups. manual says svn[serve] has blanket control
> which i understood that any user authenticated with svn[seve] would
> access all of the repositories.
> i set up a system with mod_svn_authz but not comfortable with it because
> it brings up some administrative load. most suitable solution seems ssh
> tunnel but users won't have ssh login. (ftp is possible if it helps)
Unfortunately users need SSH login if you're using svn+ssh. But you
could assign constrained shells to their accounts.
> i try to build up a solution where:
> * everyone will have read access to all of the repositories
> * only users of the group where, repos folder is owned by will have
> write access
> * giving access to other users will be as simple as "add a new user to
> the system, add this user to the repos' group"
Have a look at "The svn+ssh:// server checklist":
The only simple way I've found is using Red Hat's "group per user" user
management style. Each user has his own group and also belongs to
additional groups. In your case you'll have to use an umask which is not
necessarily acceptable at your place (by default all files are created
to be readable by everyone):
Create a Subversion user/group, for example svn/svn. The repository
top-level directory should belong to group svn and have the following
access rights so that everyone is able to read it (note that the "set
group ID" bit is set on that directory) and only those belonging to
group svn are able to write to it:
$ ls -dl /repos
drwxrwsr-x 7 svn svn 4096 may 1 00:00 /repos
Only users that belong to group svn can write to the repository. New
files belong to group svn.
Finally each project should have its own group, for example pro. The
project top-level directory should belong to group pro and the "set
group ID" bit must be set:
$ ls -dl /repos/project
drwxrwsr-x 7 pro pro 4096 may 1 00:00 /repos/project
Only users that belong to group pro can write to the project. New files
belong to group pro.
For more complex security schemes, you'll have to use ACLs. See for example:
> i am thinking of adding svn as a subsytem to ssh like sftp, but is on
> hold until it is the last choice :)
I'd be interested on feedback if you implement that...
> what may be the solution for this scenario?
It seems there's no definitive answer. For example see:
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue May 4 10:00:06 2004