

Re: file perms in the db dir

From: Davy Durham <pubaddr_at_davyandbeth.com>
Date: 2004-09-20 22:18:40 CEST

Dominic Anello wrote:

>On 2004-09-20 13:54:19 -0500, Davy Durham wrote:
>> On linux I'm setting up a svnserve environment also using websvn for
>>viewing from the web. For the difference in users (user svn vs user
>>apache) I've just made apache a member of the svn group. So as long as
>>all the files in the db dir are group writable and owned by svn
>>everything is fine.
>>Well, all is well until after many operations it creates a new
>>log.000000## file and perms are wrong, and sometimes the new log file is
>>owned by apache instead of svn if websvn caused the creation of the log
>>My question is in DB_CONFIG can I specify perms that the new file will
>>be created with? Or can it be done with sticky bits on the db dir itself?
>>I've looked at the sleepycat docs and didn't see anything. And I wasn't
>>sure if something in svn was setting the perms itself.
>>It'd just like the files to be owned by svn and perms be 664
>You should set the sticky bit on the DB directory and make sure all
>repository access is with a 002 umask. AFAIK neither BDB nor svn does
>anything with its permissions.
Ok, I had tried already to set the user and group sticky bits on the db
dir, but that didn't work. So I suppose the umask is important.
Do I need to alter any code to make sure the umask is 002? (umask is
new to me.. but I just read about it in man) It's an attribute of the
process that will be creating files. So how do I make sure it is 002
for both the websvn php scripts (I can easily edit that) AND svnserve
(which I can't edit without recompiling and I didn't compile svnserve in
the first place, but I suppose I could)? Seem like a good config
parameter or something if it isn't already. Maybe I could exec the real
svnserve from a bash script where I can set it.

Then again.. (as I was just looking around on google) I found:
http://svnbook.red-bean.com/svnbook-1.0/ch06s05.html which might answer
all my questions :)


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
Received on Mon Sep 20 22:19:08 2004

