Redmine appliance changing folder owner and groups

Preston's picture

Hello,

I love that the latest Redmine appliance auto-creates repos for projects. I seem to have broken something, however. I noticed that I could not connect to one of two repos over svn+ssh (the server is on TKLHUB) after I created a new project with SVN repository from the Redmine web interface. I went to the folder over the CLI and found that its owner permissions were www-data:root. This is exactly backwards, so I ran

chown -R root:www-data project2

to fix it. I could now connect over svn+ssh. Then I went into the Redmine web application and attempted to check to repository for project 2. I got an error saying it couldn't access it. I refresh the page and it worked. But then I go back to the CLI and find that the folder permissions are once again www-data:root. The other project doesn't seem to have this issue.

What gives?

Thanks


UPDATE: I changed the redmine cron job to reflect the behavior I was expecting. It now reads:

WEBROOT=/var/www/redmine

* * * * * root ruby $WEBROOT/extra/svn/reposman.rb --redmine localhost --svn-dir /srv/repos/svn --owner root --group www-data --url file:///srv/repos/svn --key-file $WEBROOT/api_key 2>&1 >> /var/log/reposman.log

I think things are working. Hopefully I didn't break anything!

Jeremy Davis's picture

TBH I'm not particularly familiar with the Redmine appliance. According to our default script, the owner is www-data (with no group specified). As redmine runs under the www-data user, it would make sense that you would lose access via the webUI when you change the owner to anything other than www-data.

Then my guess is the issue is that the user and group permissions are out of whack. Ideally in this usage scenario, you'll want the user and the group to have the same level of access. I.e. in octal, we are looking for something like 770, 660, 550, etc. FWIW, they work like this: user|group|everyone and the numbers come from read=4, write=2, execute=1; you just add them up. So 640 means the owner/user will have read & write, the group will have read only and everyone else has no access at all. I hope that makes sense...

Just to make this a little more tricky, directories use the execute bit (i.e. 1) a little differently to files. For files it means exactly what you'd expect, i.e. whether or not the user/group/etc can execute the file. For directories it is known as the "search" or "list" bit as it's what allows listing the contents of a directory. So in our scenario, directories will need 770 (read, write, execute to user and group, nothing for everyone else). But for files you'll only want 660 (read and write but no execute for user and group, nothing for everyone else). Luckily we can leverage find to fix that.

cd /srv/repos/svn
chown -R www-data:root .
find . -type d -exec chmod 770 {} \;
find . -type f -exec chmod 660 {} \;

So hopefully that should solve your issue. Please let me know how you go and if that resolves the issue. If not, perhaps you are right and we aren't setting it up quite how it needs to be...

Post new comment