OT: Re: [scponly] subversion support

[wby oblyr]

Hi guys,

sorry to chime in so late, but i agree that these should be handled seperately and both should default 
to disabled.  I think the patch looks perfect.  I'm going to review and commit it shortly for 4.1 
release.

thanks to both of you for looking into this...

joe


Kaleb Pederson wrote this message on Fri, Apr 08, 2005 at 09:10 -0700:
> 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


> _______________________________________________
> scponly mailing list
> scponly at lists.ccs.neu.edu
> https://lists.ccs.neu.edu/bin/listinfo/scponly