Hello, We should not need to run any hooks to setup permissions. The problem is that the repository is not setup to be "shared", which tells Git to manage the permissions correctly. You can enable this with the command: git config sharedrepository 1 Because of this, it is likely that our permissions might be a bit messed up, so we may have to fix them up once. In particular, all directories should have the `setgi` bit, the files should have the correct group permissions. The easiest way to get to this state is probably to copy the group permissions from the user ones (probably with a judicious use of `find`). -Iavor On Mon, Jul 22, 2013 at 3:46 AM, Austin Seipp wrote:

This should be fixed, try again. I went ahead and added 'chmod -R g+rw' to the post-receive hook, although I don't know why none of the other repositories require it, and all of them seem to have the correct permissions. Maybe I can look into it next time I push.

On Mon, Jul 22, 2013 at 4:56 AM, Simon Marlow wrote:

...

I tried and failed to push to the testsuite repo today.

$ git push Counting objects: 12, done. Delta compression using up to 8 threads. Compressing objects: 100% (7/7), done. Writing objects: 100% (7/7), 695 bytes, done. Total 7 (delta 5), reused 0 (delta 0) error: insufficient permission for adding an object to repository database ./objects

fatal: failed to write object error: unpack failed: unpack-objects abnormal exit To simonmar@darcs.haskell.org:/srv/darcs/testsuite.git ! [remote rejected] master -> master (n/a (unpacker error)) error: failed to push some refs to 'simonmar@darcs.haskell.org:/srv/darcs/testsuite.git'

It looks like we're not setting group write permission correctly after commits:

simonmar@ghc:/home/darcs/testsuite.git/objects$ ls -l total 136 drwxr-sr-x 2 ezyang darcs 4096 Jul 20 22:53 02 drwxr-sr-x 2 simonmar darcs 4096 Jul 22 09:51 0a drwxr-sr-x 2 ezyang darcs 4096 Jul 20 18:13 0f

I vaguely recall that we used to do this with a post-commit hook to do a 'chmod g+w -R' on the tree. Could someone look into this please?

Cheers, Simon

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

-- Regards, Austin - PGP: 4096R/0x91384671

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Hi, changing the default umask on the entire server is not necessary to fix this problem. Git already has support for exactly this use case---it will set the file permissions correctly, we just need to specify that this is a shared repository. The command to run is: git config core.sharedRepository true (I missed the "core" in my previous e-mail, and I just noticed that my correction went only to Austin). -Iavor core.sharedRepository When group (or true), the repository is made shareable between several users in a group (making sure all the files and objects are group-writable). When all (or world or everybody), the repository will be readable by all users, additionally to being group-shareable. When umask (or false), git will use permissions reported by umask(2). When 0xxx, where 0xxx is an octal number, files in the repository will have this mode value. 0xxx will override user’s umask value (whereas the other options will only override requested parts of the user’s umask value). Examples: 0660 will make the repo read/write-able for the owner and group, but inaccessible to others (equivalent to group unless umask is e.g. 0022). 0640 is a repository that is group-readable but not group-writable. See git-init(1). False by default. On Mon, Jul 22, 2013 at 3:11 PM, Ian Lynagh wrote:

On Mon, Jul 22, 2013 at 10:56:45AM +0100, Simon Marlow wrote:

...

I vaguely recall that we used to do this with a post-commit hook to do a 'chmod g+w -R' on the tree.

I've now set the default umask on the new server to be 002, and I've chmod'ed the current trees, so I think it will be OK now.

Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

On 23/07/13 00:04, Ian Lynagh wrote:

On Mon, Jul 22, 2013 at 03:51:49PM -0700, Iavor Diatchki wrote:

...

changing the default umask on the entire server is not necessary to fix this problem. Git already has support for exactly this use case

Well, I don't mind if someone wants to do the git thing too, but I think we want a umask of 002 regardless.

I tried my push again, and although it seems to have gone through, I got a ton of spewage: $ git push Counting objects: 12, done. Delta compression using up to 8 threads. Compressing objects: 100% (7/7), done. Writing objects: 100% (7/7), 698 bytes, done. Total 7 (delta 5), reused 0 (delta 0) remote: To git@github.com:ghc/testsuite.git remote: a68ec88..ee47e6e master -> master remote: chmod: changing permissions of `/home/darcs/testsuite.git': Operation not permitted remote: chmod: changing permissions of `/home/darcs/testsuite.git/packed-refs': Operation not permitted remote: chmod: changing permissions of `/home/darcs/testsuite.git/hooks': Operation not permitted remote: chmod: changing permissions of `/home/darcs/testsuite.git/hooks/applypatch-msg': Operation not permitted Iavor's fix sounds right to me. Maybe we should make a ticket? Cheers, Simon