OT: Re: [scponly] subversion support

[Kaleb Pederson]

On Friday 08 April 2005 9:37 am, Dimitri Papadopoulos-Orfanos wrote:
> > 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. [...]
>
> Why wouldn't that work? I'm a bit worried because that's what I'm
> setting up right now.
>
> My understanding is that 'svn:' and 'svn+ssh:' are different with
> respect to access rights. Using 'svn+ssh:' svnserve is run as the user
> who actually logged in through SSH. Using plain 'svn:' svnserve is
> always run as the same single user (which leaves you with Subversion
> blanket access control and doesn't help much indeed).

Yes, you understand correctly in this respect.

> So in the svn+ssh: case it should be possible to enforce access to the
> files based on user, groups, and file permissions:
> http://svnbook.red-bean.com/en/1.1/ch06s03.html#svn-ch-6-sect-3.4
> Could you please elaborate on this:
> 	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.

Ok... Here is a small sample:

username at host username $ mkdir -p tmp/svntest && cd tmp/svntest
username at host svntest $ svnadmin create --fs-type fsfs repos
username at host svntest $ svnadmin verify repos
* Verified revision 0.
username at host svntest $ mkdir co && cd co
username at host co $ mkdir project1 project2 project3
username at host co $ svn import . -m "import" 
file:///home/username/tmp/svntest/repos
Adding         project1
Adding         project2
Adding         project3

Committed revision 1.
username at host co $ cd /home/username/tmp/svntest/repos
username at host repos $ ls
conf  dav  db  format  hooks  locks  README.txt
username at host repos $ ls db
current  fs-type  revprops  revs  transactions  uuid  write-lock
username at host repos $ ls db/revs
0  1
username at host repos $ find . -type d -print
.
./db
./db/revs
./db/transactions
./db/revprops
./dav
./conf
./hooks
./locks

Ok.  Given the above, I just created three directories per one of the 
recommended structures. At this point, I need to give user A access to 
project 1, user B access to project2, and user C access to project3.

Looking at the filesystem structure and knowing that we created a hierarchy of 
projects, we can see that /project{1,2,3} don't exist anywhere on the 
filesystem.  Thus, at the filesystem level, even if we have distinct users 
because we are using svn+ssh, I can't set permissions such that users can be 
allowed in one directory but not in another.

So, I now have to resort to the permissions capabilities of svnserve which are 
enumerated here: http://svnbook.red-bean.com/en/1.1/ch06s03.html

Quoting from the above page: "While svnserve itself does not provide any means 
to control per-path authorization, a pre-commit hook can be used to enforce 
per-path write access control. The Subversion distribution comes with 
commit-access-control.pl and the more sophisticated svnperms.py scripts for 
use in pre-commit scripts."

Note that they say "write access control".  There isn't a way to control read 
access control.

> Also, just wondering, if you prefer 'https:' to manage access rights,
> why not use 'https:' in the first place instead of this combination of
> ssh and subversion?

I am using it.... the people are using the svn command over ssh.  The 
repository they are hitting is https based.  The reason is because we need a 
checkout on the web server.  They do *not* have shell access, just scponly 
access which gives them sftp and the svn commandline interface.

I hope this helps.... (and that you don't have too much work re-structuring 
your setup :).

--Kaleb