On Mon, Nov 1, 2010 at 9:36 AM, David Weintraub <qazwart_at_gmail.com> wrote:
> It's very simple. All files in the repository must be read/writeable to the
> user who is running the server side process. For the file:/// protocol, it's
> the user doing the checkout. For svn://,it's the user who is running
> svnserve. For http://, it's the user running httpd.
And when you run "svnadmin hotcopy", it's entirely ignored and
replicated as whoever does the hotcopy, even if you do it as the root
user. This breaks any management of write permissions for both the
"svn" user and the "apache" user, as might be done for a shared group
with both svn+ssh:// or svn:// access and HTTP access, or direct
file:/// access on the local filesystem, or hook scripts that are
locked and owned by an administrative user.
It's a longstanding problem, exacerbated by the distinct access
requirements of each of the distinct access technologies. It is by no
means "simple".
I've too often had to clean up after this kind of handwaving works,
for a little while, but then breaks as soon as one small factor is
changed.
> The files don't have to be owned by the user. For example, the user might be
> a member of a group with read/write access. However, when a new revision is
> written, the new revision will be owned by the user running the server
> process.
> Normally, you don't use the file:/// protocol except for private
> repositories. Otherwise, all users can directly manipulate the source
> repository itself. In fact, I never use file:/// even on my private
> repository. It's easy enough to run svnserve on my machine.
> Have the svnserve and httpd processes owned by the same user and drop
> file:/// access. Then chown the files to that user and set permissions on
> all files to 664.
This is non-trivial for security reasons. The 'apache' user may run
various back end tools, such as locally built PHP based technologies,
that you do *not* want overwriting or messing with your Subversion
repositories, especially the configuration files, without very careful
thought. Conversely, switching Apache to run as as a designated 'svn'
user can create all sorts of problems with ownership of log files or
working web repositories.
Received on 2010-11-01 22:48:58 CET