On Thu, Jul 21, 2011 at 6:12 AM, Andy Canfield <andy.canfield_at_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?
Received on 2011-07-21 16:33:53 CEST