3

I got some Mercurial repositories which are served by Apache over HTTP. But there is a dedicated user performing some automated tests, which needs to check out the repositories locally. Recently this started to fail, seemingly due to lacking rights for files in the largefiles subdirectory in .hg:

-rw------- 2 www-data www-data 6.3M 2012-01-02 17:23 9358b828fb64feb37d3599a8735320687fa8a3b2

Default umask should be 022. And I used the setgid settings for the directories in .hg according to the multiple committers wiki page, which does not cover .hg/largefiles though. However, as far as I understand it, setting the gid for this directory wouldn't solve the problem, that hg sets such restrictive rights on those files. My other user trying to access this repositories via the filesystem is also in the www-data group, thus an additional read right for group would be sufficient to solve my problem.

How can I convince Mercurial, or the system to grant this right properly for new files?

I am using: Mercurial Distributed SCM (version 2.1)

Martin Geisler
  • 194
haraldkl
  • 133

2 Answers2

2

I don't know if there's a Mercurial answer, but here's a generic answer, which may or may not work depending on exactly how Mercurial chooses file permissions.

Enable access control lists (ACLs) on the filesystem. (See this answer for instructions.) Then set the default ACL and the current ACL for the working copy to allow access to the additional user or group that requires access.

setfacl -R -d -m group:www-data:rwx /path/to/working/copy
setfacl -R -m group:www-data:rwx /path/to/working/copy
Community
  • 1
Gilles 'SO- stop being evil'
  • 829,060
  • Thanks a lot! I actually found this answer with the setfacl already, however right now I do not have ACLs activated on that system and would rather opt for a solution which would work without them. – haraldkl Feb 17 '12 at 17:50
  • I'm trying this exact method, the default g:www-data:r-x is set /path/to/repo and /path/to/repo/.hg However if I do an hg pull on the server, sometimes the files in /path/to/repo/.hg/store do not get created with default permissions and fail to be read by apache for other users. They're not large files, and I have to continuously do setfacl -Rm g:www-data:r-x /path/to/repo. Any ideas why this happens? – Budric Jun 05 '12 at 14:28
  • @Budric Not offhand. It might have something to do with how hg operates. Please ask a new question. Give as much detail as you can (ideally, show how to reproduce this issue from hg init onwards). – Gilles 'SO- stop being evil' Jun 05 '12 at 18:33
2

It turns out that this is a problem in Mercurial and that there isn't an easy work-around for Mercurial 2.1. I've just sent three patches to the Mercurial mailinglist to fix this — hopefully you'll see the fix in Mercurial 2.1.1 in a week.

The problem is that the largefiles extension is creating the .hg/largefiles/<hash> files by writing data into a temporary file which is then later renamed to the real name. It creates its temporary files using the standard tempfile module in Python. The module restricts the permissions to 600 since you normally don't want anybody to read your temporary files. The largefiles extension didn't take this into account and just renamed the file.

My patches fix this by taking the permissions of .hg/store into account when creating the temporary files. This should bring largefiles into line with the rest of Mercurial.

Martin Geisler
  • 194