Now that you mentioned it, I do remember reading in an FAQ about the SSH option... Hmmm, subversion is looking better & better. I printed off Chapters 1-6 of the Subversion book yesterday & will look over it this weekend.
Any gotchas I should be on the lookout for if we switch to subversion?
| [reply] |
..which again suffers from a larger security hole than a properly-scoped ACL that does not require local user accounts.
As far as I know, without a SERIOUSLY locked down chroot (i.e. no logins allowed whatsoever), you can't let non-local users use ssh. You need to create a local account for them on the physical box (or LDAP, or whatever you use). This opens a potential hole in your security, pending someone exploiting the client machine or network (which, as you know, you can never trust or validate).
If someone has a trusted account on your box(es), they can always try "Exploit-of-the-week" to try to gain root or consume unnecessary resources of the machine proper. These can be controlled with limits(5) and chroot(8), but those too, require considerations of their own.
With a system using ACLs, and no local user accounts, you can be sure that even if the user's machine, network, or password were somehow sniffed or exploited in some way as to compromise their access to their repository, it does not compromise your server running those repositories.
Requiring a local account, ssh, cvs, login, or otherwise, is always going to be less secure than a system that works without the use of that constraint. See comp.security.misc and comp.security.ssh for more information on these issues. Subversion is definately a contender for personal repositories, and public repositories where absolute security is not an issue, but those should be determined by the administrator who needs to install, maintain, and manage those repositories. | [reply] |
