Please correct me if I'm wrong, but it looks to me as if the only
reasonable recommendation for file ownership/permissions of a repository
that uses Apache for commit access is to have the repository owned
by the 'apache' user.
I've been running Subversion on a Mandrake Linux 10.0 system using the Mandrake
supplied packages for Subversion 1.1.0, and Apache 2. The init scripts
used to start all the system services include a set of standard functions
(/etc/init.d/functions) that immediately set the default umask to 022.
I initially tried setting up the Subversion repository to be owned by
a unique account called 'svn', with group 'svn', and added 'apache' to the
'svn' group, and set the access permissions on all the files to include
group write.
The problem I ran into was that when the db log files rolled over, the new
log file was owned by 'apache', and group 'svn' (the group SUID bit was
set on the repository directory). But the new db log file didn't have
group write permission.
Changing the umask value for httpd in the init script solved this problem,
but it seems more desirable to me to have all the file permission problems
that have to do with the repository kept with the repository.
Or is this a bug with the way db log files are handled? The Sleepcat
documentation claims that db files are created by default with group
write permission, and it looks to me like the Subversion code uses
mode 0666 to create the database. But the process umask overrides the
mode value passed to open calls, anyway. So it looks to me that if
the repository is to be owned by some account other than the one Apache
uses, that Apache has to run with umask 002 (which some sites might
consider undesireable).
At the very least, it seems that a sentence could be added to the SVN book
in the "Supporting Multiple Repository Access Methods" section.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 9 05:25:27 2004