2017-08-05 2 views
0

Nous avons un serveur Solaris sur notre campus où tous les étudiants et membres du personnel ont un compte. Je veux héberger un dépôt Git nu et le rendre accessible uniquement à certains utilisateurs. Maintenant, parce que je n'administre pas le serveur, je ne peux pas déranger avec les groupes et les comptes d'utilisateurs. Je sais que je peux utiliser Giotlite et créer des clés publiques pour mes utilisateurs, mais cela semble stupide car ils ont déjà leurs propres comptes d'utilisateurs sur le serveur. Donc, ce que je fais est d'utiliser FACL pour donner accès à des utilisateurs spécifiques.fatal: impossible d'exec 'hooks/update': Autorisation refusée lors de l'utilisation de Git

Voici ce que je l'ai fait pour mettre en place la prise en pension à l'aide cs101 compte sur son répertoire personnel (il est le compte du cours):

  1. J'ai créé un répertoire pour le repo: mkdir cs101.git
  2. Régler le FACL autorisations à l'aide pour donner accès à mon compte utilisateur

    setfacl -m d:u::rwx,d:g::---,d:o:---,d:m:rwx cs101.git 
    setfacl -m d:u:cs101:rwx,u:cs101:rwx,d:u:welcomb:rwx,u:welcomb:rwx cs101.git 
    
  3. Puis finalement initialiser Git

    cd cs101.git 
    git init --bare --shared 
    

La liste des répertoires montre

total 88 
drwx--S---+ 7 cs101 cs101  4096 Aug 3 14:33 . 
drwx-----x 6 cs101 cs101  4096 Aug 5 15:02 .. 
drwxrws---+ 2 cs101 cs101  4096 Aug 3 14:33 branches 
-rw-rw----+ 1 cs101 cs101  126 Aug 3 14:33 config 
-rw-rw----+ 1 cs101 cs101  73 Aug 3 14:33 description 
-rw-rw----+ 1 cs101 cs101  23 Aug 3 14:33 HEAD 
drwxrws---+ 2 cs101 cs101  4096 Aug 3 14:33 hooks 
drwxrws---+ 2 cs101 cs101  4096 Aug 3 14:33 info 
drwxrws---+ 33 cs101 cs101  4096 Aug 5 15:10 objects 
drwxrws---+ 4 cs101 cs101  4096 Aug 3 14:33 refs 

L'autorisation pour les répertoires semble correcte

# file: hooks/ 
# owner: cs101 
# group: cs101 
user::rwx 
user:cs101:rwx    #effective:rwx 
user:welcomb:rwx    #effective:rwx 
group::rwx     #effective:rwx 
mask:rwx 
other:--- 
default:user::rwx 
default:user:cs101:rwx 
default:user:welcomb:rwx 
default:group::--- 
default:mask:rwx 
default:other:--- 

en utilisant encore le cours compte cs101, je pousse certains fichiers dans le repo.

Maintenant, je compte vous déconnecter de cours et vous connecter en utilisant mon propre compte utilisateur et je suis en mesure de cloner le repo [email protected]$ git clone ~cs101/cs101.git

Jusqu'à présent, si bon, tout semble bien.

Maintenant, le problème est que je suis incapable de pousser les nouveaux commits retour à la prise en pension en utilisant mon propre compte utilisateur:

[email protected]$ GIT_TRACE=1 git push 
trace: built-in: git 'push' 
trace: run_command: 'git-receive-pack '\''/home/course/cs101'\''' 
trace: exec: '/bin/bash' '-c' 'git-receive-pack '\''/home/course/cs101'\''' 'git-receive-pack '\''/home/course/cs101'\''' 
trace: built-in: git 'receive-pack' '/home/course/cs101' 
trace: run_command: 'pack-objects' '--all-progress-implied' '--revs' '--stdout' '--thin' '--delta-base-offset' '-q' 
trace: exec: 'git' 'pack-objects' '--all-progress-implied' '--revs' '--stdout' '--thin' '--delta-base-offset' '-q' 
trace: built-in: git 'pack-objects' '--all-progress-implied' '--revs' '--stdout' '--thin' '--delta-base-offset' '-q' 
trace: run_command: 'unpack-objects' '--pack_header=2,3' '-q' 
remote: trace: exec: 'git' 'unpack-objects' '--pack_header=2,3' '-q' 
remote: trace: built-in: git 'unpack-objects' '--pack_header=2,3' '-q' 
trace: run_command: 'rev-list' '--objects' '--stdin' '--not' '--all' 
trace: exec: 'git' 'rev-list' '--objects' '--stdin' '--not' '--all' 
trace: built-in: git 'rev-list' '--objects' '--stdin' '--not' '--all' 
trace: run_command: 'hooks/update' 'refs/heads/master' '629b5b1f0122de95bd4e7b50a7968e64aaef6e65' 'b2072da84ee7d3fde6c6daf2cae61dbae6b0a5d9' 
fatal: cannot exec 'hooks/update': Permission denied 
remote: error: hook declined to update refs/heads/master 
trace: run_command: 'gc' '--auto' '--quiet' 
trace: exec: 'git' 'gc' '--auto' '--quiet' 
trace: built-in: git 'gc' '--auto' '--quiet' 
To /home/course/cs101 
! [remote rejected] master -> master (hook declined) 
error: failed to push some refs to '/home/course/cs101' 

Il semble qu'il est incapable d'exécuter hooks/update.

fatal: cannot exec 'hooks/update': Permission denied 

Mais hooks/update peu exec est même pas défini, ce qui signifie Git doit ignorer l'exécuter.

/home/course/cs101/cs101.git/hooks$ getfacl update   

# file: update            
# owner: cs101            
# group: cs101            
user::rw-              
user:cs101:rwx   #effective:rwx      
user:welcomb:rwx  #effective:rwx    
group::rw-    #effective:rw-      
mask:rwx              
other:---              

/home/course/cs101/cs101.git/hooks$ ls -al update   
-rw-rw---- 1 cs101 cs101  2910 Aug 4 10:50 update 

Je peux accéder aux fichiers dans les répertoires et même exécuter update.sample en utilisant mon compte

/home/course/cs101/cs101.git/hooks$ ./update.sample 
Don't run this script from the command line. 
(if you want, you could supply GIT_DIR then run 
    ./update.sample <ref> <oldrev> <newrev>) 

Je ne peux pas comprendre pourquoi pousser Git ne parvient pas à mettre à jour la prise en pension.

+0

La sortie de 'getfacl' suggère qu'il est * exécutable pour' user: welcomb', donc Git tentera de l'exécuter. On ne sait pas pourquoi cela échouerait par la suite (est-ce interprété étant donné la petite taille du fichier, j'imagine, si oui, l'autorisation de l'interprète est-elle refusée?). – torek

+0

L'umask pour 'update' n'est pas exécutable, et en effet je ne peux pas l'exécuter depuis le terminal. Pensez-vous que Git pense que c'est exécutable depuis l'acl et essaie de l'exécuter? Et comment puis-je vérifier si c'est interprété? Je ne comprends pas très bien ce que tu veux dire. – welcomb

+0

Git appelle 'access (path, X_OK)' de sorte que cela dépend de ce que l'appel 'access' du système renvoie, mais je m'attendrais à ce qu'il préfère les ACL sur les bits de mode' stat'. Quant à ce que signifie être un fichier interprété, voir https://linux.die.net/man/2/execve – torek

Répondre

1

La sortie getfacl comprend les lignes:

user:cs101:rwx   #effective:rwx  
user:welcomb:rwx  #effective:rwx         

ce qui signifie que la fonction de bibliothèque access(path, X_OK) C est susceptible de prétendre que le fichier peut être exécuté (dirigé par l'intermédiaire d'un appel de système execve ou similaire), à moins pour les utilisateurs cs101 et welcomb. C'est ainsi que Git détermine si un hook est exécutable.

(Notez que tout autre utilisateur appelant access va obtenir la réponse. non, ce fichier est exécutable Cela fait partie de ce qui rend ACLs si compliqué.)

Lorsque le système d'exploitation essaie réellement l'exécuter, cependant, quelque chose d'autre ne va pas. Ce n'est pas tout à fait clair ce qui se passe mal, mais l'appel système execve échoue avec une erreur «autorisation refusée». Git décide alors que ce crochet a échoué, plutôt que le crochet n'était pas réellement exécutable (Git suppose que access dira pas plutôt que oui pour ces cas). Compte tenu de la petite taille du fichier (2910 octets, à partir de la sortie ls -al update), il semble peu probable que le hook update soit autre chose qu'un script shell. Si est un script shell, il a besoin d'une ligne d'interpréteur #! correcte pour être exécutable, et cette ligne d'interpréteur doit pointer vers un fichier qui a lui-même des permissions d'exécution.

Si vous voulez que le hook s'exécute, vous devrez retracer la source de la panne réelle. Si vous ne pas voulez que le crochet s'exécute, et ne voulez pas Git à pensez le crochet devrait devrait exécuter, supprimer les bits d'exécution des divers éléments de la liste de contrôle d'accès, ou supprimer complètement la liste de contrôle d'accès (ACL et Les autorisations de type "Unix" sont souvent des entités distinctes dans le système sous-jacent, bien que ZFS soit différent ici).