On Thu, Jul 21, 2011 at 6:12 AM, Andy Canfield <andy.canfi...@pimco.mobi> wrote:
> ADDENDUM ...
>
> I used root to create the /data/svn directory. Then, anticpiating problems,
> I did a chmod to make it writable to all.
>
> Later I ran svnadmin create /data/svn/sample and it created an entire
> repository directory tree under /data/svn. I don't remember but I probably
> ran it as root.
>
> I just now noticed that /data/svn/sample and all the sub-directories and
> files therein are owned by root and, usually, writable only by root. This is
> probably going to cause problems for Apache / mod_dav_svn which, of course,
> runs as the 'apache user' ("www-data") instead of root.
>
> Where did I go wrong? The manual talks about commands but does not seem to
> talk about what user is executing the command. Do I have to run svnadmin as
> www-data? Is there a way to create a repository using my browser?Welcome to sys-admin hell, the "documentation is true, but not complete" world that I've spent so many years in. The connections between different pieces of information that are obvious to someone who's been through similar issues in the past are not obvious to a an intelligent but new person like yourself. It goes back to "what are you trying to achieve". If you're setting up an svn+ssh repository with direct user logins, various components need to be owned with "write" permissions for those users. This is typically done by putting users in a particular authorized group, such as "project1" for the "project1" repository at /var/svn/project1. The configuration files, such as /var/svn/project1/conf/ and /var/svn/project1/scripts, can be owned by any user or group, as long as the connecting user has appropriate read or execute access. If you're setting it up for web access, it needs to have the writable /var/svn/project1/db directory writable by whatever user runs the HTTP daemon, typically "apache" or "www-data" on modern Linux systems. If you're setting up both web access and svn+ssh, your life becomes more interesting and we could review that. It's tricky to do well. /var/svn/project1/db directory needs write access for the users. All of them. When you use the kind of shared permission access you've selected based on active local logins, you've given up control of that directory to all the local users. It is theoretically possible to set up cron job that scans that directory and resets ownership to a local "svn" user of all successfully loaded revisions, and set the directory permissions to 1777 to prevent users deleting each other's revisions, but without such chicanery you cannot defend this file in that kind of "shard access" setup. This is also where you get into trouble with your ideal of "locking down individual files". Individual working copy files aren't stored in the database, they are *assembled* from the list of revisions involved in modifying that file throughout that file's history. This is partly why the most viable Subversion models of preventing individual file or difectory modifications are all in the pre-commit stages, not in the database structure itself. And unfortunately, this sort of chicanery is not replicated for backups: if you run "svnadmin hotcopy" to copy your repository, it will not preserve the funky ownerships, and you'll need to deal with it again. Andy, it really sounds like you're getting caught up in the small details. What *must* you have? Access for everyone with a valid system login, or a designated list of users? Can your people use SSH keys, which can seriously simplify ownership issues, and will HTTPS access serve their needs?
