Git - 多个用户使用相同的工作目录：.git 元文件中的权限问题

Git - multiple users using the same working dir: permissions issues in .git meta-files

提问by kghastie

The Issue:when multiple users have access to the same working directory, permissions issues can occur in the meta-data if any gitoperations are performed.

问题：当多个用户可以访问同一个工作目录时，如果git执行任何操作，元数据中可能会出现权限问题。

DISCLAIMER: Before you chastise me - I realize sharing a working dir is counter to what Git stands for, and I am not talking about doing anything other than read-only operations in this shared directory - we do all our work in our own local repositories.

免责声明：在你责备我之前 - 我意识到共享一个工作目录与 Git 所代表的意思背道而驰，我不是在谈论在这个共享目录中做只读操作以外的任何事情 - 我们在我们自己的本地存储库中完成所有工作.

I'm open to suggestions as to another way to do what we are trying to do, as our approach is certainly not best practice, but I'm not sure that conversation that would be useful for others to listen to. So for now let me provide some details on why we are doing this:

我愿意接受关于我们正在尝试做的事情的另一种方法的建议，因为我们的方法当然不是最佳实践，但我不确定这种对话是否对其他人有用。所以现在让我提供一些关于我们为什么这样做的细节：

We have several build-masters on our team. We deploy to Linux servers, and we do our builds there, with build scripts that pull directly from Git. We are not able to use CI (such as Jenkins/cruisecontrol) at this time, so we have a repository that we checkout and do our QA builds from.

我们的团队中有几位构建大师。我们部署到 Linux 服务器，并在那里进行构建，使用直接从 Git 中提取的构建脚本。我们目前无法使用 CI（例如 Jenkins/cruisecontrol），因此我们有一个存储库，我们可以从中检出并进行 QA 构建。

There are some git operations that we perform as part of the script. This includes some tagging of commits (stuff gets tagged as QA-current, QA-previous, etc...). So I guess we aren't actually read-only entirely. Due to the nature of the build script, we run it sudo'ed as a common user (let's call that user DevAdmin). I realize this might be a bad practice, and is perhaps the source of the pain, since it forces us to use a shared repo checkout.

我们在脚本中执行了一些 git 操作。这包括一些提交的标记（东西被标记为 QA-current、QA-previous 等......）。所以我想我们实际上并不是完全只读的。由于构建脚本的性质，我们sudo以普通用户（我们称该用户为 DevAdmin）的身份运行它。我意识到这可能是一种不好的做法，并且可能是痛苦的根源，因为它迫使我们使用共享的 repo checkout。

This would all be fine, if we were always sudo'ed when in that working dir. The issue is that on occasion, one of us will do a git pullor something similar by accident, without being sudo'ed as DevAdmin. So most of the files in .gitare owned by DevAdmin (who performed the initial clone), but whenever we do this, we end up with dir's in .git/objectsthat contain files owned by a specific user. And these are created as group-unwritable. I've also noticed ORIG_HEADwith wrong ownership, for example. So when we try to do something as DevAdmin, we get issues.

如果我们在那个工作目录中总是被 sudo 操作，这一切都会好起来的。问题是，有时，我们中的一个人会git pull无意中做类似的事情，而没有被 sudo'ed 为 DevAdmin。因此，其中的大部分文件.git都归 DevAdmin（执行初始克隆的人）所有，但是每当我们这样做时，我们最终.git/objects都会得到包含特定用户拥有的文件的目录。这些被创建为组不可写。例如，我还注意到ORIG_HEAD错误的所有权。因此，当我们以 DevAdmin 身份尝试做某事时，我们会遇到问题。

Is there anything that we can do to fix this issue? Right now, we have to recognize that it has happened, and then get a server admin to chown .gitback to DevAdmin. Or have the user delete the meta-files in question, or at least chmodthem to group-writable. This all seems very bad.

我们可以做些什么来解决这个问题？现在，我们必须认识到它已经发生，然后让服务器管理员chown .git回到 DevAdmin。或者让用户删除有问题的元文件，或者至少将chmod它们设置为组可写。这一切看起来都非常糟糕。

I've considered a couple of options that don't involve changing our build and maintenance processes dramatically:

我已经考虑了几个不涉及显着改变我们的构建和维护过程的选项：

If we removed group-write access on .gitand restricted it to DevAdmin, would that prevent this from happening again? This seems the most straightforward option.

如果我们删除了组写入权限.git并将其限制为 DevAdmin，是否可以防止这种情况再次发生？这似乎是最直接的选择。

Or is there a way to make everything in .git group-writable, even when it's newly created? This seems like asking from trouble.

或者有没有办法使.git 组中的所有内容都可写，即使它是新创建的？这似乎是在自讨苦吃。

Is there something else obvious I'm missing? I realize that the best thing would probably be to change our process so that users could work in their own repo's, but in a business setting, the repos can get very large (jars aren't separated out yet, lots of binary files, etc...), and we can't have multi-GB repos for everyone's account. Additionally, our system administrators would have a lot of work ahead of them changing their processes to allow for it.

还有什么明显的我遗漏了吗？我意识到最好的办法可能是更改我们的流程，以便用户可以在他们自己的存储库中工作，但是在业务环境中，存储库可能会变得非常大（jar 尚未分离，大量二进制文件等...)，而且我们不能为每个人的帐户提供多 GB 的存储库。此外，我们的系统管理员在更改他们的流程以允许它之前还有很多工作要做。

Any thoughts are appreciated.

任何想法表示赞赏。

回答by Todd A. Jacobs

There are a number of waysto address this problem. Personally, I'd recommend the following in your existing repository:

有多种方法可以解决这个问题。就个人而言，我建议您在现有存储库中使用以下内容：

# Create a group named "gitshare" that will share the repository.
sudo groupadd gitshare

# Add yourself and as many others as you want to the group.
sudo adduser "$LOGNAME" gitshare

# Everything else needs to run from the top level of your Git repository.
cd /path/to/repository

# Add group permissions for *new* modifications to repository.
git init --shared=group

# Fix permissions for existing repository objects.
chown -R :gitshare "$PWD"
chmod -R g+swX "$PWD" 

Obviously, you need to make sure that the users have directory traversal permissions all the way to your repository (e.g. user-private directories may cause problems), and that all team members who need access belong to the repository's shared group. After this initial setup, though, it should "just work."

显然，您需要确保用户对您的存储库一直具有目录遍历权限（例如，用户私有目录可能会导致问题），并且所有需要访问权限的团队成员都属于存储库的共享组。但是，在此初始设置之后，它应该“可以正常工作”。

回答by MyraGe

I just faced this issue and took me hours to find the solution when it was so simple. I tried almost everything I see on the other link provided by CodeGnome.

我刚遇到这个问题，花了几个小时才找到解决方案，因为它很简单。我几乎尝试了我在 CodeGnome 提供的另一个链接上看到的所有内容。

I'm using Centos 6.x and the solution was to change the umask on users... this require we do it with each account... We are only 2 working on the same directory. Not that much of a pain.

我正在使用 Centos 6.x，解决方案是更改用户的 umask……这要求我们对每个帐户都这样做……我们只有 2 个在同一目录上工作。没有那么痛苦。

The solution that worked for me is this one, without having to change the server's configuration: http://www.avajava.com/tutorials/lessons/how-do-i-set-the-default-file-and-directory-permissions.html

对我有用的解决方案是这个，无需更改服务器的配置：http: //www.avajava.com/tutorials/lessons/how-do-i-set-the-default-file-and-directory-权限.html

If the .bashrc filoe do not exists in /home/user directory, like this was in my case, you only need to copy from the skeleton the file in /ect/skel and then you copy it your home (users) directory after adding at the end of the file:

如果 /home/user 目录中不存在 .bashrc 文件，就像我的情况一样，您只需要从骨架中复制 /ect/skel 中的文件，然后在添加后将其复制到您的主（用户）目录中在文件末尾：

umask 002

This gives the user a chmod 775 on the new folders created by others in the group. Of course, once this project will be completed, not anymore in a testing environment, we will set it back to chmod 755 (umask 022) by default. This not only give Git the permission to overwrite but also to write files uploaded on sFTP without having the permission denied issue. .

这为用户提供了对组中其他人创建的新文件夹的 chmod 775。当然，一旦这个项目完成，不再在测试环境中，我们将默认设置回chmod 755（umask 022）。这不仅赋予 Git 覆盖的权限，还允许写入上传到 sFTP 的文件，而不会出现权限被拒绝的问题。.