让 git push 尊重权限? [英] Making git push respect permissions?

问题描述

我们使用托管在远程位置并共享的 git 存储库.我们希望 repo 是 user &组可读&可写，但对其他人没有任何权限.远程仓库归不同的用户所有(比如 rUser).我已经在我的本地仓库和远程仓库中将 core.sharedRepository 设置为 0660 .另外，我的 umask 是 0027.因此，每当我创建一个新文件时，它都没有其他权限.

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.

尽管如此，出于某种原因，每当我将更改推送到远程存储库时，它都会在 repo.git/objects/ 目录中创建一些具有权限 -r 的新对象--r--r--.更奇怪的是，它使我(而不是远程用户)成为目录/文件的所有者.知道发生了什么吗?

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?

我试图通过在 stackoverflow 上查看几个看似相关的问题来寻找答案，但什么也找不到.

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

推荐答案

注意:我假设您正在使用基于 SSH 的访问机制，每个用户都以自己的用户身份登录服务器(即您没有多个用户登录到单个帐户以访问存储库).如果这个假设不成立，那么下面的答案可能并不完全有用.

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.

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

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.

在远程存储库中将 core.sharedrepository 设置为 0660 是获得所需内容的正确方法.远程端访问用户的 umask 也无关紧要，因为 Git 在看到 core.sharedrepository 的 0xxx 值时会覆盖掩码.您确实需要确保所有文件和目录都归公共组所有，并且权限正确(2770 用于所有目录(或仅 770 用于所有目录)BSD-ish 系统)；440 用于 objects/?? 和 /objects/pack/ 下的文件；660其他文件).

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).

新文件归创建它的用户所有是正常的.在非 BSD 系统上，您需要目录上的 setgid 位(2000 位)以使新条目继承其父目录的组所有者.用户所有者很少被继承(FreeBSD 可以配置为使用 setuid 位来实现，但这在正常配置中不使用).因此，所有文件和目录都应该具有相同的、共同的、组所有者，但是每次对存储库的写入(例如推送)都会留下一些由写入用户拥有的文件和/或目录¹(即不需要任何一个用户(您的 rUser?)是所有文件和目录的用户所有者；任何需要访问存储库的用户都应该是普通组).

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).

<子>¹每个用户显然将拥有他们创建的任何文件/目录，但他们也将拥有他们修改的大多数文件，因为 Git 使用原子重写"(它将新内容写入同一目录中的一个新的单独文件，然后将其重命名为原始文件).

_{¹ 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).}

也许 Git 覆盖新文件的 umask 的方式存在错误.究竟哪些文件获得的权限太宽?您在远程端使用哪个版本的 Git 来访问存储库?您在远程端运行的是什么操作系统?

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?

我无法使用 Git 1.7.4.1 在我的 Unixy 机器上用两个用户和一个公共组重现这个问题.

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

您可以尝试稍微简化一下场景.尝试直接从服务器本身推送到远程存储库(即制作本地克隆并推送到一次性分支).与中间有某种传输相比，仅进行本地访问可以更容易地检查您的假设(umask；uids；gids；用户和组所有权，以及推送之前和之后的文件和目录的权限)(Git 自己的基于 SSH 的传输，或者可能无法完全保真地映射 ID 和权限的网络文件系统).

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 push 尊重权限?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！