Git post-receive hook permissions

[kinderpindakaas]

Ik heb momenteel op mijn VPS een multi-user git omgeving gemaakt voor externe programmeurs.
Ik beheer de gebruikers middels gitolite en het idee was dat elke programmeur de push resultaten zou kunnen zien op bijv. http://dev.example.com

Dat laatste wilde ik realiseren met een post-receive hook.

Gitolite en alle repo's draaien onder de gebruiker "git"
Stel ik de hook: /home/git/repositories/project.git/hooks/post-receive als volgt in:

code:

#!/bin/sh
GIT_WORK_TREE=/home/git/webdocs git checkout -f

Dan komen de files na een push vanaf mijn workstation perfect aan in de directory "webdocs"
Echter als example.com je hoofd domein naam is en je wilt dat bestanden na een push in dev.example.com terecht komen, dan moet je in een andere user zijn mappen gaan porren.

code:

#!/bin/sh
GIT_WORK_TREE=/home/example/public_html/dev git checkout -f

Echter dan werkt het niet meer:

code:

$ git push
Counting objects: 3, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 234 bytes, done.
Total 2 (delta 1), reused 0 (delta 0)
remote: fatal: Could not switch to '/home/example/public_html': Permission denied
To ssh://[e-mail]:22/project.git
   e3f0e83..98d9d0a  master -> master

NOTE: eigen domeinnaam ff vervangen voor example.com

Ik heb al vanalles geprobeerd:
- user git toevoegen aan root group
- user git toevoegen aan apache group
- dev folder heel extreem op chmod 777
- git line in /etc/passwd aangepast zodat hij in group 0 (root) komt
- dev folder chown naar root:root en ook een keer naar git:git

Wat opvallend is dat hij zegt Could not switch to '/home/example/public_html': ipv Could not switch to '/home/example/public_html/dev

Iemand suggesties wat ik nog zou kunnen proberen?

[deadinspace]

kinderpindakaas schreef op woensdag 17 juli 2013 @ 23:10:
- user git toevoegen aan root group
- git line in /etc/passwd aangepast zodat hij in group 0 (root) komt

Dat zou ik niet doen. Een voordeel van het draaien van een service onder een aparte user is dat hij beperkte rechten heeft. Door een user aan de root group toe te voegen geef je hem mogelijk meer rechten dan je lief is (maar zoals je al gemerkt hebt, niet de rechten die je zoekt).

Die twee aanpakken doen zo ongeveer hetzelfde trouwens.

- dev folder heel extreem op chmod 777

Dat zou ik ook niet doen.

- dev folder chown naar root:root en ook een keer naar git:git

De dev folder, ja. Maar hoe zit het met de bovenliggende public_html? Of example? Je foutmelding gaat niet voor niets over /home/example/public_html

Wat opvallend is dat hij zegt Could not switch to '/home/example/public_html': ipv Could not switch to '/home/example/public_html/dev

Dus: wat zijn de permissies op /home/example en /home/example/public_html?

[kinderpindakaas]

Ik geef toe dat mijn aanpak vrij extreem is, maar dat was meer voor het debuggen.
Permissies op /home/example en /home/example/public_html staan alleen voor owner op writable.

Je zou idd group ook schrijfrechten kunnen geven, maar dat is ook tricky.
Dan kan user git in de hele boom van example schrijven.
Terwijl je het liefste de git user alleen schrijfrechten tot de folder dev wilt geven

[deadinspace]

kinderpindakaas schreef op donderdag 18 juli 2013 @ 22:50:
Permissies op /home/example en /home/example/public_html staan alleen voor owner op writable.

Je zou idd group ook schrijfrechten kunnen geven, maar dat is ook tricky.

Waarom zou je dat willen? git hoeft toch niet te schrijven in /home/example/public_html? Hij moet alleen de directory "dev" daarin kunnen bezoeken.

Wat zijn de exacte permissies op /home/example en /home/example/public_html?

[kinderpindakaas]

User git wil met de hook een git checkout uitvoeren op mijn dev folder.
Hij wil dus schrijfrechten hebben.

/home/example is:
drwx--x--- 8 example access 4096 Jul 11 22:26 example

/home/example/public_html is:
lrwxrwxrwx 1 example example 31 Jul 3 2012 public_html -> ./domains/example.nl/public_html

user git is lid van de example group
uid=510(git) gid=511(git) groups=511(git),0(root),48(apache),506(example)

[ Voor 9% gewijzigd door kinderpindakaas op 19-07-2013 00:19 ]

[deadinspace]

kinderpindakaas schreef op vrijdag 19 juli 2013 @ 00:17:
User git wil met de hook een git checkout uitvoeren op mijn dev folder.
Hij wil dus schrijfrechten hebben.

Schrijfrecten in /home/example/public_html/dev ja, niet in /home/example/public_html

/home/example is:
drwx--x--- 8 example access 4096 Jul 11 22:26 example

Ok, dat lijkt me prima.

/home/example/public_html is:
lrwxrwxrwx 1 example example 31 Jul 3 2012 public_html -> ./domains/example.nl/public_html

Nouja, dat is een symlink, daar hebben we niet zoveel aan. Wat zijn de permissies op /home/example/domains, /home/example/domains/example.nl en /home/example/domains/example.nl/public_html?

user git is lid van de example group
uid=510(git) gid=511(git) groups=511(git),0(root),48(apache),506(example)

En nog van de root group, dat wil je misschien even rechtzetten

[kinderpindakaas]

Wat me niet duidelijk is of user git lid moet zijn van alle groepen van bovenliggende mappen.

/home is bijvoorbeeld van root:root
Vandaar dat ik uit voorzorg ook maar git aan root heb toegevoegd.

Maar bottom-line zou user "git" toevoegen aan de example group voldoende moeten zijn toch?
En dan folder /dev op chmod 775 zetten.

[kinderpindakaas]

Ok let op

Ik krijg het alleen als volgt werkend:

/home/example heeft als permissions example:access (710)

User git is lid van group access, maar als je vanuit git user naar /home/example wilt kom je er niet in.

chmod ik /home/example naar (711) zodat "other" ook execute rechten krijgt, dan kom ik er wel in en werkt ook de post-receive hook.

Vreemd toch?
User git is lid van group access, maar toch accepteert hij dat op de één of andere manier niet.

update: Het hele probleem gevonden. Je moet user git uit en inloggen willen zijn permissions effect hebben

[ Voor 11% gewijzigd door kinderpindakaas op 19-07-2013 15:49 ]

[CAPSLOCK2000]

Dat is een algemene regel (of gebrek) onder Unix, groepen worden pas actief nadat je opnieuw inlogt.

[Sendy]

kinderpindakaas schreef op vrijdag 19 juli 2013 @ 15:32:
update: Het hele probleem gevonden. Je moet user git uit en inloggen willen zijn permissions effect hebben

Nee, dat is niet zo. Permissies zijn direct actief. De lijst van groepen wordt in het proces opgeslagen; deze lijst wordt niet vervangen bij een aanpassing van /etc/groups. Dáárom moet je uitloggen.

[Jeanpaul145]

Is hier ooit nog iets uitgerold?

Ik zit met een vergelijkbaar probleem en ik heb er nog geen oplossing voor gevonden.
Een verse clone, handmating git init doen, het is allemaal irrelevant en helpt niet.

Hooks blijven "permission denied" wat nergens op slaat gegeven dat mijn user alle lees- en schrijfrechten heeft die t maar kan hebben.

Voorlopige conclusie: git developers done fucked up.