SVN file permissions

Submitted by rrhode on Thu, 05/27/2010 - 18:04

Hello you awesome people you,

I have found what seems to be a bug in the file permissions in SVN. I have an SVN set up in Virtualmin Pro. I have Trac installed through the Script Installer.

I am using Eclipse to work on the SVN and it works fine. But then when I go to Trac it says:

Warning: Can't synchronize with the repository (Couldn't open Subversion repository /home/domain.com/svn/repo: SubversionException: ("Can't open file '/home/domain.com/svn/repo/db/current': Permission denied", 13)). Look in the Trac log for more information.

So I look at the permissions of the "/svn/repo/db/current" file and it is owned by apache:apache whereas all the other files in that folder are owned by apache:domaingroup

When I run "chown apache:domaingroup current" I can then browse the source in Trac again, until I do anything in Eclipse and then the file goes back to apache:apache and the error in Trac comes back. Running Fix Permissions in Virtualmin doesn't fix it.

Thanks =)

Ryan

Status: 
Closed (fixed)

Comments

Submitted by JamieCameron on Thu, 05/27/2010 - 19:51

Are you using Eclipse to access the repository via HTTP?

Also, are all the files in the repository mode 770 (user and group writable) ?

Submitted by rrhode on Wed, 09/01/2010 - 07:38

Hey, I just noticed this is still a problem and guess I missed the email about your reply or something.

Basically it happens if I am using Eclipse or not, the problem happens also when I am using svn command from my local Linux the shell. I use the command: svn co http://mydomain.com/svn/project

Then when I commit I just do: svn commit

The directory and file permissions are -rwxrwx--- So I guess that is in fact 770.

Sometimes a particular file within the SVN directory will become Apache grouped instead of grouping to the SVN user making it so that Trac can't access the SVN and I get a message from Trac. The file permissions change when I upload to the SVN. I can go and manually switch it back to the proper user and the Trac error goes away but as soon as I upload to SVN again it comes back. I will do a test to get more details on the problem.

Ok, I just checked out the entire SVN project to a fresh directory. I deleted a useless branch. When commiting to SVN via command line it works fine with no errors or anything. But then Trac will show this error:

Warning: Can't synchronize with repository "(default)" (Couldn't open Subversion repository /home/mydomain.com/svn/project: SubversionException: ("Can't open file '/home/mydomain.com/svn/project/db/current': Permission denied", 13)). Look in the Trac log for more information.

There is also no Browse Source button now.

Now when I list files at /home/mydomain.com/svn/project/db all files have permissions set as apache:mydomaingroup except for the file named "current" which is set to apache:apache. Changing the permissions to apache:mydomain causes the Trac error to go away and everything is back to normal. The Fix Permissions button doesn't do anything. Commiting to SVN again causes the problem again.

Submitted by rrhode on Wed, 09/01/2010 - 07:53

I just realized there are some other files under some of the other folders inside the /home/mydomain.com/svn/project/db folder which also have the same permission problem happening to them when a commit is done.

It looks like they are the revision# files located under db/revs and db/revprops

I am currently running the command "chown -R apache:mydomaingroup db" which is fixing everything until another commit is done.

Submitted by JamieCameron on Wed, 09/01/2010 - 16:00

What are the full directory permissions for /home/mydomain.com/svn/project/db ?

It should have the setgid bit set, which you can do with chmod g+s /home/mydomain.com/svn/project/db .. they will cause newly created files to inherit the group of the parent.

Submitted by rrhode on Wed, 09/01/2010 - 18:26

Ah nice, thanks, I forgot about that sort of thing. It seems to be a problem in all my repos though, not just this project. I don't know what the cause is exactly. Maybe SVN is configured wrong by default or something.

That doesn't seem to fix the files inside the revs and revprops folders still for some reason though even if I chmod g+s those two as well...

Ok after testing it seems that doing chmod -R g+s /home/mydomain.com/svn/project/db was the thing that worked. Keeps the errors from coming back after commits. I guess having a recursive g+s bit is necessary for the svn db.

Submitted by JamieCameron on Wed, 09/01/2010 - 19:04

I will have the SVN plugin to Virtualmin use g+s permissions on directories by default in the next release to avoid this issue ..

Submitted by rrhode on Wed, 09/01/2010 - 19:21

Awesome, sounds good to me =) Thank you!

Submitted by Issues on Wed, 09/15/2010 - 21:20

Automatically closed -- issue fixed for 2 weeks with no activity.