git-使用相同工作目录的多个用户:.git元文件中的权限问题 [英] Git - multiple users using the same working dir: permissions issues in .git meta-files

问题描述

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

The Issue: when multiple users have access to the same working directory, permissions issues can occur in the meta-data if any git operations 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.

我愿意就其他尝试做的方式提出建议，因为我们的方法当然不是最佳实践，但是我不确定这种对话对其他人倾听有用吗到.因此，现在让我提供一些为什么要这样做的细节:

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

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.

作为脚本的一部分，我们执行了一些git操作.这包括一些提交标记(将内容标记为QA当前，QA先前等).因此，我想我们实际上并不是完全只读的.由于构建脚本的性质，我们以普通用户身份运行它sudo(我们将该用户称为DevAdmin).我意识到这可能不是一个好习惯，也许是痛苦的根源，因为它迫使我们使用共享的回购结帐.

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 pull或类似的操作，而不会被当做DevAdmin.因此，.git中的大多数文件都由DevAdmin(执行初始克隆)拥有，但是每当执行此操作时，我们都会在.git/objects中以dir结束，该目录包含特定用户拥有的文件.并且这些被创建为组不可写.例如，我还注意到ORIG_HEAD拥有错误的所有权.因此，当我们尝试以DevAdmin身份进行操作时，就会遇到问题.

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 pull or something similar by accident, without being sudo'ed as DevAdmin. So most of the files in .git are owned by DevAdmin (who performed the initial clone), but whenever we do this, we end up with dir's in .git/objects that contain files owned by a specific user. And these are created as group-unwritable. I've also noticed ORIG_HEAD with wrong ownership, for example. So when we try to do something as DevAdmin, we get issues.

我们有什么办法可以解决此问题?现在，我们必须认识到它已经发生，然后让服务器管理员将chown .git回到DevAdmin.或者让用户删除有问题的元文件，或者至少将它们chmod进行组写.这一切似乎都很糟糕.

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 .git back to DevAdmin. Or have the user delete the meta-files in question, or at least chmod them to group-writable. This all seems very bad.

我考虑了一些不涉及显着改变构建和维护流程的选项:

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

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

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

或者是否有一种方法可以使.gi t组中的所有内容都可写，即使是新创建的?这似乎是在麻烦中问.

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

还有其他明显的我想念的东西吗?我意识到最好的办法可能是更改我们的流程，以便用户可以在自己的存储库中工作，但是在业务环境中，存储库会变得非常大(尚未分离出jar文件，很多二进制文件，等等). ...)，我们无法为每个人的帐户提供数GB的存储库.此外，我们的系统管理员需要做很多工作，才能更改流程以适应需要.

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.

任何想法都值得赞赏.

推荐答案

有一个

There are a number of ways to 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."

这篇关于git-使用相同工作目录的多个用户:.git元文件中的权限问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！