让git推尊敬权限？ [英] Making git push respect permissions?

问题描述

我们使用托管在远程位置的git repo，并进行共享。我们希望回购是用户&组可读&可写，但不具有其他权限。远程回购由不同的用户拥有（如rUser）。我在本地仓库以及远程仓库中设置了 core.sharedRepository 到 0660 。另外，我的umask是 0027 。所以，无论何时我创建一个新文件，它都没有其他权限。尽管如此，由于某种原因，每当我将更改推送到远程仓库时，它都会在 repo.git中创建一些新对象/ objects / 目录的权限 -r - r - r - 。更奇怪的是它让我（而不是远程用户）成为目录/文件的所有者。任何想法发生了什么？

我尝试通过查看几个看似相关的stackoverflow问题找到答案，但找不到任何东西。

$ b $注意：我假设你使用基于SSH的访问机制，每个用户都以自己的用户身份登录服务器（即你没有多个用户登录到一个帐户访问存储库）。如果这个假设不是真的，那么下面的答案可能不是完全有用的。

---

core.sharedrepository 您的个人存储库设置和用于访问它的 umask 与远程存储库上使用的所有权和权限无关。

在远程存储库中设置 core.sharedrepository 到 0660 是正确的方式你说什么你想要的。远程端的访问用户的 umask 也是无关紧要的，因为当它看到 0xxx 值时，Git将覆盖掩码C> core.sharedrepository 。您需要确保所有文件和目录都由您的公共组所有，并且所有目录的权限都是正确的（ 2770 ）（或者 770 用于BSD-ish系统）; 440 用于 objects / ?? 和 / objects / pack / ; 660 用于其他文件）。



创建它的用户拥有一个新文件是正常的。在非BSD系统上，需要目录上的setgid位（ 2000 位>）以使新条目继承其父目录的组所有者。用户拥有者很少被继承（FreeBSD可以配置为使用setuid位来完成，但是这在正常配置中不会使用）。因此，所有的文件和目录应该有相同的通用的组所有者，但是每次写入存储库（例如推送）都会留下用户拥有的一些文件和/或目录。 1 < （即不要求任何一个用户（您的 rUser ？）是所有文件和目录的用户所有者;任何需要访问存储库应该是普通组的成员）。

$ p $ b $ sup $ 1
每个用户显然都是用户自定义的，拥有他们创建的任何文件/目录，但他们也将用户拥有他们修改的大多数文件，因为Git使用原子重写（它将新内容写入同一目录中的新独立文件，然后将其重命名为原始文件）。


也许在Git覆盖新文件的umask方面存在一个错误。究竟哪些文件获得的权限太宽？您在远程端要在存储库上访问什么版本的Git？你在远程端运行什么操作系统？

我无法用Git 1.7.4.1在Unixy机器上有两个用户和一个公共组。 / p>

您可以尝试简化场景。尝试直接从服务器本身推送到远程存储库（即，建立本地克隆并推送到丢弃分支）。只进行本地访问可以更容易地检查您的假设（umask; uids; gids;用户和群组所有权，以及在推送前后的文件和目录的权限），而不是在中间有某种类型的传输（Git自己的基于SSH的传输，或者可能无法完全保真地映射ID和权限的网络文件系统）。

We use a git repo that is hosted at a remote location, and is shared. We want the repo to be user & group readable & writeable, but not have any permissions for other. The remote repo is owned by a different user (say rUser). I have set core.sharedRepository to 0660 in my local repo, as well as the remote repo. Also, my umask is 0027. So, whenever I create a new file, it has no permissions for other.

In spite of all this, for some reason whenever I push a change to the remote repo, it creates some new objects in the repo.git/objects/ directory with permissions -r--r--r--. What's even weirder is that it makes me (instead of the remote user) the owner of the directories/files. Any idea what's going on?

I tried finding an answer by going over several seemingly related questions on stackoverflow, but couldn't find anything.

解决方案

Note: I am assuming that you are using an SSH-based access mechanism with each user logging into the server as their own user (i.e. you do not have multiple users login to a single account to access the repository). If this assumption is not true, then the following answer may not be wholly useful.

---

The core.sharedrepository setting of your personal repository and the umask you use to access it are irrelevant to the ownership and permissions used on a remote repository.

Setting core.sharedrepository to 0660 in the remote repository is the right way to get what you say you want. The umask of the accessing user on the remote side is also irrelevant because Git will override the mask when it sees a 0xxx value for core.sharedrepository. You do need to make sure all the files and directories are group-owned by the your common group and that the permissions are correct (2770 for all directories (or just 770 for BSD-ish systems); 440 for files under objects/?? and /objects/pack/; 660 for other files).

It is normal that a new file is user-owned by the user that created it. On non-BSD systems you need the setgid bit (the 2000 bit) on directories to make new entries inherit the group-owner of its parent directory. The user-owner is rarely inherited (FreeBSD can be configured to do it with the setuid bit, but this is not used in normal configurations). Thus, all the files and directories should have the same, common, group-owner, but each write to the repository (e.g. push) will leave some files and/or directories that are user-owned by the writing user¹ (i.e. it is not required that any one user (your rUser?) be the user-owner of all the files and directories; any user that needs access to the repository should be a member of common group).

_{¹ Each user will obviously user-own any files/directories they create, but they will also user-own most files that they modify because Git uses "atomic rewrites" (it writes the new content to a new, separate file in the same directory, and then renames it atop the original file).}

Maybe there is a bug in the way Git is overriding the umask for new files. Exactly which files are getting permissions that are too wide? What version of Git are you on the remote end to access on the repository? What OS are you running on the remote end?

I was unable to reproduce this problem with Git 1.7.4.1 with two users and a common group on my Unixy machine.

You might try simplifying the scenario a bit. Try pushing to the remote repository directly from the server itself (i.e. make a local clone and push to a throw-away branch). Doing local-only access makes it easier to check your assumptions (umask; uids; gids; user-, and group-ownership, and permissions of files and directories before and after pushing) than when you have a transport of some kind in the middle (either Git’s own SSH-based transports, or a network filesystem that might not map ids and permissions with full fidelity).

这篇关于让git推尊敬权限？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！