Some comments on FAQ + book regarding svn+ssh

Hello there. Nice work you do - reminds me the time we were
thinking to write a new source control in my previous company...

Here are some remarks/precisions/questions regarding svn+ssh
documentation. I am sorry I can't afford spending too much
time on sending you a proper patch (which I'd have liked to
do), but my english is not so good anyway.

If you really want a patch, please tell me and I could do it,
but I have something like 500 items with higher priority to
tackle with before and cannot promise anything for the next
6 months (at least ;-P)

Hoping this helps (and will help many people), here is the
raw stuff.
Please Cc me for comments, I can't afford reading svn-devel
too (Oh yes, I would with pleasure, if only I had the time :-P).

----------------------------------------

FAQ: How do I set repository permissions correctly?

> If your clients are accessing via file:/// or svn+ssh://, then
> there's no way to avoid access by multiple users

NOK for svn+ssh, if the users don't have their own account on the server
but are using a shared svn account, with public keys in
.ssh/authorized_keys

SVNBOOK: Server Configuration - Overview

I would distinguish and emphasis on the two ways of using the
svn+ssh method:

1. Using system accounts
2. Using only one subversion account, with public user keys
   in .ssh/authorized keys.

This would add a fourth column in the Table 6.1:
* svnserve/ssh, one shared account
User account options: public keys in authorized_keys
Authorization options :
  why does this differ from svnserve ?
Initial setup: somewhat simple.

(personally, I would not recommend the 'system accounts' solution,
for security reasons, and for the need to configure many accounts)

SVNBOOK: Choosing a Server configuration

Ditto, split svn+ssh in two:
* svnserve over ssh becomes svnserve over ssh (using many ssh accounts)
 Cons: remove "or use a shared ssh key"
       add bullet * Need to maintain many accounts (+security risks?)
       add bullet * Can't set fine-grained permissions on the repository

* Add svnserve over ssh (one svn account, pubkeys in authorized_keys)
 Pros: - Network protocol is stateful and noticeably faster than WebDAV.
       - No need to define many user accounts
       - All network traffic is encrypted
 Cons: - Only one choice of authentication method.
       - No logging of any kind, not even errors.
       - Need to manage the keys for the users

Could someone tell me if the bullet "Can't set fine-grained permissions
on the repository" also applies ? Since svnserve can be notified
of the tunneled user (via --tunnel-user=...) why would it not be able
to handle permissions like standard svnserve ? (note that I did not
investigate this point yet.)

Recommendations, 4th bullet
 "If you have an existing infrastructure heavily based on SSH accounts"

> If your deep desire for encrypted communication still draws you to
> this option, we recommend using Apache with SSL instead.

I would add "or use the svn+ssh method with a shared ssh account
and pubkeys listed in authorized_keys"

I would add the following recommendation: (not that I experienced it,
but it is obvious that it is dangerous)

If using svn+ssh, choose either the method using one ssh account
for each user, or the one using pubkeys in authorized_keys, but don't
mix them - oh no, don't.

Tunneling over SSH: should distinguish the 2 cases defined above.

Cheers

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