Existe uma maneira de impedir que o git altere as permissões e a propriedade na recepção?

Toda vez que faço git pullou git reset, gitresets muda para permissões e propriedade que fiz. Veja por si mesmo:

#!/usr/bin/env bash
rm -rf 1 2

mkdir 1
cd 1
git init
echo 1 > 1 && git add 1 && git ci -m 1

git clone . ../2
cd $_
chmod 0640 1
chgrp http 1

cd ../1
echo 12 > 1 && git ci -am 2

cd ../2
stat 1
git pull
stat 1

A saída:

$ ./1.sh 2>/dev/null | grep -F 'Access: ('
Access: (0640/-rw-r-----)  Uid: ( 1000/    yuri)   Gid: (   33/    http)
Access: (0664/-rw-rw-r--)  Uid: ( 1000/    yuri)   Gid: ( 1000/    yuri)

Existe uma maneira de contornar isso?

Quero tornar alguns arquivos / diretórios acessíveis para gravação pelo servidor da web.

permissions git

— x-yuri
fonte

Parece que o usuário que você está executando tem o grupo padrão definido como yuri. Você pode confirmar isso assim:

$ id -a
uid=1000(saml) gid=1000(saml) groups=1000(saml),10(wheel),989(wireshark)

O UID da sua conta é este: uid=1000(saml)enquanto o grupo padrão é git=1000(saml)e quaisquer grupos secundários são a partir de então.

NOTA: Se você deseja que o clone git tenha propriedade específica, você tem pelo menos 2 opções.

Opção 1

Defina um diretório pai com as permissões conforme desejado:

$ mkdir topdir
$ chgrp http topdir
$ chmod g+s topdir

$ cd topdir
$ git clone ....

Isso forçou o diretório topdira impor todos os diretórios filhos abaixo dele para que o grupo fosse httpaplicado. Isso funcionará de maneira geral, mas poderá causar problemas, pois se você mover arquivos para esse espaço de trabalho do clone do git, esses arquivos não terão seus grupos aplicados pelas alterações feitas acima.

Opção 2

Antes de fazer o trabalho, altere seu grupo padrão para httpo seguinte:

$ newgrp http
$ git clone ...

Esse método forçará qualquer novo arquivo criado a ter seu grupo definido como em httpvez do grupo padrão normal de yuri, mas isso funcionará apenas desde que você lembre de fazer um newgrptrabalho anterior a trabalhar neste espaço de trabalho.

Outras opções

Se nenhum deles parecer aceitável, tente usar ACLs no diretório da área de trabalho git. Eles são discutidos em várias perguntas e respostas neste site, como as perguntas e respostas intituladas: Obtendo novos arquivos para herdar permissões de grupo no Linux .

— slm
fonte

Primeiro, você deve ter significado newgrp. Então, ele muda de grupo apenas para o shell atual? E, finalmente, o objetivo era tornar apenas arquivos / diretórios específicos acessíveis para gravação pelo servidor da web. Afinal de contas, eu provavelmente deveria corrigi-los manualmente, ou configurar algum gitgancho ...

— x-yuri

@ x-yuri - desculpe, são 5 da manhã aqui e estou prestes a ir para a cama 8-). Sim, isso persiste apenas para o shell atual, o que seria uma desvantagem dessa abordagem. Se você pretende apenas um certo acesso ao servidor da Web, isso será complicado, e você provavelmente desejará usar ACLs. Além disso, convém adicionar esses detalhes ao seu Q. Como está, não está claro qual é o seu objetivo, para que eu possa responder apenas em termos não específicos.

— slm

@ x-yuri - um gancho pós-atualização como este pode ser mais adequado: stackoverflow.com/questions/9613545/…

— slm

@ x-yuri - controlar permissões é discutido no livro git sob ganchos: git-scm.com/book/en/Customizing-Git-Git-Hooks

— SLM

Na verdade, não vejo como mudar de grupo apenas para o shell atual pode ser uma desvantagem, para ser honesto. Eu estava preocupado com o fato de não mudar a maneira como o restante dos aplicativos funciona.

— X-yuri

A solução que eu uso é executar o comando como o usuário que possui as permissões que você deseja manter:

sudo -u user command

Isso impede que as permissões sejam alteradas. Eu o uso ao atualizar repositórios git no meu VPS, mantendo as permissões de arquivo definidas para o usuário do servidor da web.

Veja também a mesma pergunta aqui .

— Deleet
fonte