Philipp Marek wrote:
...
http://www.tgharold.com/techblog/2007/05/fsvs-for-sysadmins.shtml
says:
Unfortunately, the documentation for FSVS is rather sparse at the moment
Hey, that's not really nice !-) More documentation than code, if you count the
lines. :-)
Hah, I've re-written that line about 3x in the past 2 days. (It was
worse.) I'm sure I'll re-write it again once I have things figured out
and can be more objective.
:)
Another idea just crossed my mind: If you put
netcat localhost <some_port>
as command in your authorized_keys, then you can (should be able to) use a
running svnserve instance *as a completely different user* as "server" - so
that no remote access can get to the repository directly.
It would have to authorize itself via svn_auth.conf ...
I have to think about the implications of that... I suspect my objection
to that would be the use of plain-text passwords (which using SSH
avoids). At least I think that would involve the storage of plain-text
passwords on the server... I have to think about this some more when I'm
more awake.
...
I've also been thinking about the pros/cons of using a single SSH
account (with multiple entries in authorized_keys where the command=
tells svnserve which username to pretend as) as opposed to using
individual SSH accounts.
The single-account method is less work (fewer accounts created, no need
to add users to the proper lines in /etc/group). And allows you to deal
cleanly with situations where 2 people use the same machine and the same
working copy folders. By having PuTTY cache the user-specific SSH key
in Pageant, you can use a generic svn+ssh URL on the working copy and
the SVN server does the hard work of figuring out which user to
authenticate as. (It's a not-the-best scenario, but it may be something
we do. Or we'll just issue a "svn switch" command on the working copy
when the user logs in.)
But if a SSH key gets cracked / stolen / or used to break into the SVN
server, it will be difficult to tell which of the authorized_keys was
responsible for the break-in. With separate user accounts, the attacker
is more likely to leave tracks telling us which user account was used
for the break-in. So I think it's worthwhile to have individual user
accounts that belong to the group that owns the SVN repository directory.
But my thinking might be flawed on that.
I notice that the SVN book at redbean talks down using SSH in tunneling
mode due to umask issues. But once we set the ownership of the
repository folder to a unix group and set the sticky bit on the
repository/db folder (chmod -R g+s repository/db), we haven't seen any
issues with file ownership. So using a single "server" account on the
SVN server doesn't appeal to us.
We may also have the advantage in that our SVN server is single-purpose
(running in a Xen DomU). All of the accounts on it are SVN-related and
it's not trying to do 20 other duties. So we don't really worry much
about having a few dozen user accounts for machines.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
