Hi everyone,

I have a bare git repository that users in a particular group
("webdev") are pulling from and pushing to using the ssh transport.
One of the users has just reported this error during a push:

Counting objects: 103, done.
Compressing objects: 100% (68/68), done.
error: unable to write sha1 filename
./objects/4f/
973ce5c66f082af5087948cec57001f0c4da50: Permission denied

fatal: failed to write object
error: pack-objects died with strange error
error: failed to push some refs to '/var/git/myrepo.git'

I'd appreciate some help on getting my repository back to a sane
state, allowing this user to finish his push, and making sure
permissions are right in the future.

I don't think I specified "--shared=group" when initializing the
repository. Afterwards I manually set all files to have 660
permissions, dirs as 770, and set the group ownership to "webdev", but
I probably made a mistake by not setting the setgid bit on
directories. Now there are some objects directories with 755
permissions and different group ownership (the default groups of the
other users).

I have now run "git --bare init --shared=group" to reinitialize the
repository. This seems to have changed the directories to be g+sx. (Is
this all it did?). There are still some objects directories with 755
permissions rather than 770, which I presume I want, and the group
ownership of these is wrong. Shall I change these by hand? The sha1
files all have 444 permissions; is this right?

The last question I have is how to ensure that git creates object
files etc. with the right permissions when users push in future.

I'd appreciate any help!

-- Ed
--

[ message continues ]

Have a look at the config file. It should contain

[core]
        sharedrepository = 1
now.

I've never used that option before but I think this option should be
enough to ensure that it works in the future if it did for other repos
in the past..

Marc Weber
--

[ message continues ]

Hi Ed!

I'm also a newbie here and I have a very similar setup to yours.

The only difference is that my repository was created using 
git-cvsimport and afterwards I used git-config to set 
core.sharedrepository=1 and manually set up the permissions.

I also got objects created with the users' default group, but for now I 
just changed the deafault group for those users until I find a better 
solution.

Another issue with this setup: if I run git-gc in the shared repo, it 
recreate the files in logs/refs/heads with 644 permissions, which 
prevents users to push until I manually fix the permissions.

Someone else have faced these kind of problems?

Regards,

 - Samuel




--

[ message continues ]

>>>>> "Ed" == Ed Schofield <edschofield@gmail.com> writes:

Ed> I have now run "git --bare init --shared=group" to reinitialize
Ed> the repository. This seems to have changed the directories to be
Ed> g+sx. (Is this all it did?). There are still some objects
Ed> directories with 755 permissions rather than 770, which I presume
Ed> I want, and the group ownership of these is wrong. Shall I change
Ed> these by hand? The sha1 files all have 444 permissions; is this
Ed> right?

Ed> The last question I have is how to ensure that git creates object
Ed> files etc. with the right permissions when users push in future.

As Marc said, you should first make sure that "config" contains
"sharedrepository = 1" in the "[core]" section.

Then you can do the following:

  - remove all permissions for "others":  chmod -R o-rwx .
  - mirror "user" permissions to "group": chmod -R g=u .
  - add +s flag to directories:           find . -type d | xargs chmod g+s

This should fix your current situation. The "sharedrepository = 1"
will tell git to maintain a proper shared state in the future
on objects it creates (i.e. mirror "user" permission to "group" ones).

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/

--

[ message continues ]

This worked beautifully. Thanks Sam, thanks Marc!

-- Ed
--

[ message continues ]

Is git-gc supposed to respect sharedrepository=1 and create 
group-writable files?
For me, it's recreating the files under logs/refs/heads with 644 
permissions.

BR,

 - Samuel


--

[ message continues ]