OT: Re: [scponly] subversion support

[Kaleb Pederson]

Before anybody gets distracted with the rest of my e-mail, I have attached a 
patch to add support for svnserve.  It's only *lightly* tested (eg. it 
compiled for me), so I would encourage people to try it out before using it 
in a production environment.

On Friday 08 April 2005 8:05 am, Dimitri Papadopoulos-Orfanos wrote:
> > The biggest reason by far not to do what you mention is that svn+ssh
> > permissions granularity is very poor.  That is, because it happens at the
> > filesystem level, I can't control which hierarchies people have access to
> > and which one's they don't.  Using https, I can use the apache path
> > controls with fine granularity.
>
> I disagree. The granularity and general capabilities of filesystem
> permissions are not poor. Actually they may be richer than Apache's.
> It's perfectly possible to define groups at the system-level and setting
> group ID on directories. Then you also have ACLs.

I disagree -- this doesn't work as you indicated.  I have a single repository 
which I'll call svnrepos.  Our users then have "sites" that exist in that 
repository.  I have to give people access to only their site, without giving 
them access to somebody else's site.  Because of the BDB and FSFS structure, 
I can't give them just filesystem access to a single path within that tree no 
matter how many ACE's and groups I create.  In the manual they refer to it as 
per-directory access control.  See 
http://svnbook.red-bean.com/en/1.1/ch06s04.html#svn-ch-6-sect-4.4.2

There are other complicating things.  For example, everybody might need read 
access (but not write access) to /common/libs/php.  With svnserve, again this 
is impossible while still giving them authenticated write access.

> Anyway, that's not my point. The standard way of using SSH with
> Subversion is the one described in the Subversion book and Web site. I
> maybe haven't been reading Subversion documentation and mailing lists in
> enough detail, but this is the first time I hear of such a setup. As far
> as I can understand, the working copy isn't even on the user's computer,
> one has to copy files from the repository to a working copy and then
> from the working copy to the user's computer. If so, I can't believe
> this is a common scenario.

Our users have two options:
1) work on a local copy of the repository, commit, and then use ssh/scponly to 
update/commit/revert their website as needed.
2) via sftp, work on the copy of the repository on the website, and then use 
ssh/scponly to commit/update/revert etc.

I've read the book and it doesn't really address this.  There have been many 
discussions on the mailing list and irc channel about this type of thing, and 
they are all fairly similar to my situation (although *most*) use post-commit 
hooks.

A single example on the mailing list uses basically the same structure we do, 
but use public-key based command restriction instead of scponly:
http://svn.haxx.se/users/archive-2004-08/1768.shtml

> What we seem to agree on is that it would be nice to have support for
> 'svnserve'.

Yes.  Patch attached.

> What we can't agree on is the support for 'svn'. I believe it should be
> disabled by default, and 'svnserve' should be the default. But again, I
> may have missed posts on Subversion mailing list that recommend the use
> of the 'svn' setup instead of the 'svnserve' setup, or I may have
> misunderstood the complexity of the 'svn' setup.

Both are disabled by default.  My patch allows two options and adds in the 
word 'cli' for the former implementation and specifies svnserv for the new 
implementation.  I hope this makes it obvious which one is supported.

Please let me know if this patch works for you.

Thanks.

--Kaleb
-------------- next part --------------
A non-text attachment was scrubbed...
Name: svnserv.diff
Type: text/x-diff
Size: 3449 bytes
Desc: not available
Url : https://lists.ccs.neu.edu/pipermail/scponly/attachments/20050408/9d058623/svnserv.bin