On Tuesday 04 January 2005 07:34 pm, Ben Collins-Sussman wrote:
> On Jan 4, 2005, at 5:00 PM, Scott Lewis wrote:
> > Greetings SVNers,
> >
> > I ran into this same issue and would like to add my voice to those
> > requesting
> >
> > a) better control/appropriate handling of create file permissions with
> > svn/svn apache mod (preferred)
> > b) additional documentation for this issue...in FAQ and other docs
>
> This is documented at the end of chapter 6... is it not clear enough?
Well, no. It does explain the nature of the beast, but doesn't include
everything that's needed in order to make things work, at least on my Linux
system.
This might be a bug in the DB routines, or a problem with Linux systems, but
if the Apache process umask is 022, which is the default on my Mandrake
system, when the http access method is used to update the repository, and the
DB log files roll over, the new log file doesn't have group write permission,
since the umask of the process triggering the rollover controls the file
permission on the new log file. So when a different user tries to update the
repository, the update fails. I have group SUID bit set on the DB directory,
per the instructions at the end of Chapter 6.
On my Linux system (2.6.3 kernel, glibc 2.3.3), the setting the group SUID bit
on a directory doesn't affect the file permissions of a newly created file.
However, if the program creating the file makes a umask(2) call internally,
it can override the default process umask.
So the problem could be fixed if the DB routines would make an appropriate
umask(2) call prior to creating a new log file (or any new file, for that
matter), to guarantee that group write permission is set. Alternatively, the
init script for Apache could be changed so the default umask is 002. On my
system, the init script file is "/etc/init.d/httpd". But changing the Apache
subsystem might cause other security problems.
So an additional note about the required umask value for the Apache daemon
is in order, should the operating system not support the workaround mentioned.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jan 5 14:27:52 2005