kfogel@collab.net wrote:
> John, it appears there's no consensus on this approach being a good
> thing. I also had concerns about it, the same as Greg's and Mike's,
> but I didn't take the time to formulate them before reviewing the
> patch itself
I'll keep this patch in my own copy of subversion, since I _do_ find it to be
useful. Please consider the attached diff which improves the discussion in
Chapter 5, Section 5 on permissions with actual example code (for Unix O/S's).
Thanks all for the thought provoking discussion!
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
Index: doc/book/book/ch05.xml
===================================================================
--- doc/book/book/ch05.xml (revision 7667)
+++ doc/book/book/ch05.xml (working copy)
@@ -170,6 +170,12 @@
directory. Initially, revision 0 also has a single revision
property, <literal>svn:date</literal>, set to the time at which
the repository was created.</para>
+
+ <para>If you need to limit the local file:// access to the repository
+ to a specific user or share it with a specific group, please see
+ <xref linkend="svn-ch-5-sect-5"/>. You should also consult that
+ section for one way to set the repository permissions for access
+ via Apache or svnserver.</para>
<para>You may have noticed that the path argument to
<command>svnadmin</command> was just a regular filesystem path
@@ -2626,14 +2632,28 @@
files? Assuming you have a Unix-like operating system, a
straightforward approach might be to place every potential
repository user into a new <literal>svn</literal> group, and
- make the repository wholly owned by that group. But even that's
- not enough, because a process may write to the database files
- using an unfriendly umask—one which prevents access by
- other users.</para>
+ make the repository wholly owned by that group. Then the actual
+ repository files need to be owned by that group, with appropriate
+ rights:</para>
- <para>So the next step beyond setting up a common group for
- repository users is to force every repository-accessing process
- to use a sane umask. For users accessing the repository
+ <screen>
+$ su [enter root password]
+chown -r mgr:svn /path/to/repository
+chmod -r 0770 /path/to/repository
+ </screen>
+
+ <para>which respectively sets all files in the repository to be owned
+ by 'mgr' with 'svn' group access, and all of the files are RWX for
+ both owner and group. NOTE: that if 'svn recover' is run on a
+ repository, the group membership for some of the files (especially
+ in the reposistory/db directory may be reset to the default group
+ of the user running recover.</para>
+
+ <para>But even that's not enough, because a process may write to the
+ database files using an unfriendly umask—one which prevents
+ access by other users. So the next step beyond setting up a common
+ group for repository users is to force every repository-accessing
+ process to use a sane umask. For users accessing the repository
directly, you can make the <command>svn</command> program into a
wrapper script that first sets <command>umask 002</command> and
then runs the real <command>svn</command> client program. You
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 24 22:31:05 2003