Henrik, would it be possible to post this is 'patch' format?
You can do that like so:
$ svn co http://svn.collab.net/repos/svn/trunk/www/ svn-www
$ cd svn-www
$ vi project_faq.html ### or emacs, or whatever you use ###
$ svn diff > my-patch.txt
Then post my-patch.txt to email@example.com (or users@ -- I'll
try to watch both), with "[PATCH]" in the subject line. A short log
message at the front would help too.
"Henrik Vendelbo" <firstname.lastname@example.org> writes:
> ** CHANGE FOR: How do I set repository permissions correctly?
> ** EXISTING TEXT:
> Try to have as few users access the repository as possible. For example, run
> apache or 'svnserve -d' as a specific user, and make the repository wholly
> owned by that user. Don't allow any other users to access the repository via
> file:/// urls, and be sure to run 'svnlook' and 'svnadmin' only as the user
> which owns the repository.
> If your clients are accessing via file:/// or svn+ssh://, then there's no
> way to avoid access by multiple users. In that case, read the last section
> in chapter 6, and pay particular attention to the "checklist" sidebar at the
> bottom. It outlines a number of steps to make this scenario safer.
> Note for SELinux / Fedora Core 3+ / RedHat Enterprise users:
> In addition to regular Unix permissions, under SELinux every file,
> directory, process, etc. has a 'security context'. When a process attempts
> to access a file, besides checking the Unix permissions the system also
> checks to see if the security context of the process is compatible with the
> security context of the file.
> Fedora Core 3, among other systems, comes with SELinux installed by default,
> configured so that Apache runs in a fairly restricted security context. To
> run Subversion under Apache, you have to set the security context of the
> repository to allow Apache access (or turn off the restrictions on Apache,
> if you think all this is overkill). The chcon command is used to set the
> security context of files (similarly to how the chmod sets the traditional
> Unix permissions). For example, one user had to issue this command
> ** CHANGE FROM HERE :
> $ chcon -R -h -u system_u -t httpd_sys_content_t PATH_TO_REPOSITORYto set
> the security context to be able to successfully access the repository.
> The -u changes the security context user while the -t changes the security
> context type. The security policy configured on Fedora Core 3 does not seem
> to mind if the user is root rather than system_u, but the documentation
> states that system_u should be used, so better safe than sorry. The fedora
> team has posted a nice tutorial on SELinux at
> Since new files and directories inherit the security context of the parent
> directory you may save yourself the maintenance work by storing repositories
> in a common directory for which you have set the proper security context.
> Then you may create a repository within the parent directory without further
> context changes. Besides httpd content, configuration files are also
> accessed by Apache httpd. These should have a type of etc_t. If you maintain
> them in a directory outside /etc (in a common Subversion directory for
> instance), remember to set the security context using the command
> $ chcon -u system_u -t etc_t PATH_TO_CONF_FILE
> If you want to check the security context settings you may use a simple ls
> $ ls -aZ PATH_TO_REPOSITORY_OR_CONF_FILE
> The overall benefit you get is that SELinux puts Apache & Subversion in a
> Sandbox that allows you to configure exactly which files and directories one
> may access through settings and system policy. Even someone successfully
> hacking Apache or Subversion will not be able to gain access beyond the
> ** DONE
> To unsubscribe, e-mail: email@example.com
> For additional commands, e-mail: firstname.lastname@example.org
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Dec 10 19:03:37 2004