☰

Depuración de permisos de repositorio de git en samba share

tag-icon • tag-icon linux permissions git samba
Depuración de permisos de repositorio de git en samba share

He estado trabajando con repositorios de git clonados en samba share durante aproximadamente un año y, aparte de algunos problemas con la configuración, no hubo ningún problema. Recientemente intenté agregar algunos archivos al repositorio existente y me sorprendió ver errores de "permiso denegado".

Ahora puedo iniciar un repositorio vacío, pero cuando intento ejecutarlo strace git add test, aparece:

    open(".git/objects/info/alternates", O_RDONLY|O_NOATIME) = -1 ENOENT (No such file or directory)
    access(".git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391", F_OK) = -1 ENOENT (No such file or directory)
    open(".git/objects/e6/tmp_obj_GvIyn7", O_RDWR|O_CREAT|O_EXCL, 0444) = -1 EACCES (Permission denied)
    write(2, "error: insufficient permission f"..., 88error: insufficient permission for adding an object to repository database .git/objects
    ) = 88
    close(4)                                = 0
    write(2, "error: test: failed to insert in"..., 44error: test: failed to insert into database
    ) = 44
    write(2, "error: unable to index file test"..., 33error: unable to index file test
    ) = 33

Estoy usando git 1.8.4.2, samba 4.1.1 en Archlinux de 64 bits (versión del kernel: 3.12.1). No he cambiado nada en la configuración de git ni de samba desde hace mucho tiempo.

El recurso compartido se monta usando systemd automount en /etc/fstab:

//SERVER/DATA  /media/smb  cifs user,noauto,credentials=/etc/samba/creds,\
workgroup=PRV,uid=1000,gid=users,_netdev,comment=systemd.automount 0 0

el montaje aparece como:

//SERVER/DATA on /media/smb type cifs (rw,nosuid,nodev,noexec,relatime,vers=1.0,
cache=strict,domain=PRV,uid=1000,forceuid,gid=100,forcegid,addr=10.1.1.5,
file_mode=0755,dir_mode=0755,nounix,serverino,rsize=61440,wsize=65536,actimeo=1)

Permisos:

    $ ls -lan .git/objects
    total 0
    drwxr-xr-x 2 1000 100 0 11-27 09:04 .
    drwxr-xr-x 2 1000 100 0 2013-11-27  ..
    drwxr-xr-x 2 1000 100 0 11-27 09:39 e6
    drwxr-xr-x 2 1000 100 0 11-27 09:04 info
    drwxr-xr-x 2 1000 100 0 11-27 09:04 pack

    $ ls -lan .git/objects/pack
    total 0
    drwxr-xr-x 2 1000 100 0 11-27 09:04 .
    drwxr-xr-x 2 1000 100 0 11-27 09:04 ..

Ya lo he probado:

  • establecer diferentes permisos para compartir - mismo resultado
  • montaje manual - igual
  • degradar samba y git a versiones anteriores: no hay diferencia
  • sudo: esto funciona pero no me gustaría usarlo a menos que sea absolutamente necesario
  • mercurial (por curiosidad): la clonación del repositorio de git falla, los repositorios de hg se clonan sin ningún problema
  • cambiar de propietario y grupo después de usar sudo; parecen permanecer iguales antes y después de emitir el comando

¿Hay algo más que pueda hacer para depurarlo? Me inclino bastante a quedarme con git, pero no tengo ni idea de qué está mal con los permisos.

Respecto a sudo:

$ touch test
$ sudo strace git add test
open(".git/objects/info/alternates", O_RDONLY|O_NOATIME) = -1 ENOENT (No such file or directory)
access(".git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391", F_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, ".git/objects/pack", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 5
getdents(5, /* 2 entries */, 32768)     = 48
getdents(5, /* 0 entries */, 32768)     = 0
close(5)                                = 0
open(".git/objects/e6/tmp_obj_i4e0C8", O_RDWR|O_CREAT|O_EXCL, 0444) = 5
brk(0xd5a000)                           = 0xd5a000
write(5, "x\1K\312\311OR0`\0\0\t\260\1\360", 15) = 15
brk(0xd4a000)                           = 0xd4a000
brk(0xd3a000)                           = 0xd3a000
close(5)                                = 0
link(".git/objects/e6/tmp_obj_i4e0C8", ".git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391") = 0
unlink(".git/objects/e6/tmp_obj_i4e0C8") = 0
lstat(".git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391", {st_mode=S_IFREG|0755, st_size=15, ...}) = 0
close(4)   

$ ls -lan .git/objects/e6
total 1
drwxr-xr-x 2 1000 100  0 11-28 10:11 .
drwxr-xr-x 2 1000 100  0 11-28 10:10 ..
-rwxr-xr-x 1 1000 100 15 11-28 10:11 9de29bb2d1d6434b8b29ae775ad8c2e48c5391
-r-xr-xr-x 1 1000 100  0 11-28 10:11 tmp_obj_9Z8UgU
-r-xr-xr-x 1 1000 100  0 11-28 10:10 tmp_obj_d0yhDJ

Crea los objetos con 0755permisos. Sin sudoobjetos temporales, los archivos quedan con formato 0555. Parece que el problema está en la creación de archivos con 0444un usuario normal, lo cualparecetener permisos de escritura para todo el repositorio.

Respuesta1

Lo más probable es que haya realizado cambios en este repositorio mientras era root, probablemente por usar sudo, y ahora algunos de los archivos .gitson propiedad de root. Haga una chownpara restablecer la propiedad del archivo al usuario que utiliza habitualmente.

Respuesta2

Es un error del kernel en 3.12:https://bugzilla.kernel.org/show_bug.cgi?id=66251

Baje la versión mencionada por @bjauy o actualice a 3.13.

Respuesta3

Hubo un error en la versión del kernel que estaba ejecutando. Bajé el kernel a 3.11.6 y git add/commitel usuario comenzó a trabajar nuevamente.

Respuesta4

Linux ve su carpeta smb como en el grupo "otros". Por lo tanto, sus permisos deben ser algo así como xx7, por ejemplo, 777 si desea que todos los grupos puedan escribir en su www.

Problema, cada vez que git crea una nueva carpeta, archivo o lo que sea, lo creará usando sus propios permisos. La solución es utilizar umask, por lo que todo lo creado en nombre del usuario actual utilizará los permisos especificados. En ese caso, en la carpeta compartida de Windows, necesitarás esto:

máscara 000

por lo que todos podrán escribir en cualquier archivo nuevo, incluido el grupo "otros", eso es todo, su carpeta compartida de Windows.

Agregue esta máscara de usuario en su .bashrc y el problema se resolverá.

información relacionada