Question

我正在与一位同事共享一个git存储库，并且因为git没有传播完整的Unix文件权限，我们有一个在更新时运行的“钩子”，它设置了“其他”权限，因为它们需要组。问题？钩子使用chmod，结果是当我的同事提交文件时，他拥有它，所以我不能在其上运行chmod，反之亦然。这些目录都是可写的，粘性的，所以我相信我们任何一个人都有权删除任何文件，并用相同名称，相同内容但不同所有权的文件替换它。据推测，我们可以chmod。但这看起来像是一把非常大的锤子，而且我对它搞砸了有点怀疑。所以，有两个问题：

有人可以想到另一种方法吗？
如果没有，那么实现“让这个文件属于我”的防弹 shell脚本的最佳设计是什么？没有跨文件系统移动等等......

对于那些可能没有意识到的人，写入权限不会授予chmod的权限：

% ls -l value.c
-rw-rw---- 1 agallant ta105 133 Feb 10 13:37 value.c
% [ -w value.c ] && echo writeable
writeable
% chmod o+r value.c               
chmod: changing permissions of `value.c': Operation not permitted

我们都在ta105组。

注意：

我们使用git不仅要协调更改，还要将repo作为课程网站发布。发布网站是回购的主要目的。权限脚本使用git钩子在每次更新时运行，并确保学生无权阅读尚未公布的解决方案。
请不要暗示我的错误是umask。并非repo中的所有文件都应具有相同的权限，并且无论选择何种umask，都需要更改某些文件的权限。更不用说我对我的同事强加我的umask偏好是不礼貌的。
更新：我刚刚了解到，在我们的环境中，root在我们有权访问的所有计算机上被撤销到nobody，因此依赖于root的解决方案特权不起作用。

Answer 1

至少有一个Unix，我在其中看到了一种方法，可以对某个特定组拥有的所有文件授予chmod和chown个人权限。这有时被称为“组超级用户”或类似的东西。

我见过的唯一的Unix肯定是我在Encore Multimax运行的Unix版本。

我搜索了一下，虽然我记得在Linux中对这种能力的一些模糊引用，但我一直无法找到它们。所以这可能不是一个选择。幸运的是，它可以被模拟，虽然模拟有点危险。

模拟这个的方法是制作一个非常具体的suid程序，在检查你是拥有该文件的同一组的成员后，将chmod作为 root 执行，并且您的用户名在特殊/etc/chmod_group文件中列为具有该权限，该文件必须由 root 拥有，并且只能由 root 读取和写入。

Answer 2

最直接的方法是让你的伴侣和你成为新组的成员（让我们说“devel”），并将其作为文件组。这样它就可以被你们任何一方拥有，只要这个组合是正确的，你们都可以使用它。

如果这对您不起作用，可以配置“sudo”，以便只有这两个用户可以在没有密码的情况下以root身份对该特定目录中的文件运行chmod命令。

Answer 3

如果您正确设置了umask，则可以首先使用正确的权限创建文件：

$ umask 0022
$ touch foo
$ ls -l foo
-rw-r--r-- 1 sarnold sarnold 0 2011-02-20 21:17 foo
$ rm foo
$ umask 0002
$ touch foo
$ ls -l foo
-rw-rw-r-- 1 sarnold sarnold 0 2011-02-20 21:17 foo

Answer 4

我退后一步。如果我违反了你的系统中的某些限制我还没看过，请告诉我。

根据您的问题，我假设您正在尝试使用file://网址共享git存储库，并依赖UNIX文件系统权限来处理授权等。为什么不考虑另一种方式来共享您的不涉及这种麻烦的存储库？

我可以想到两种方式。

您可以在任一台计算机上创建裸存储库，将其作为远程工具添加到您的工作存储库并使用它进行协作。可以使用内置的git daemon命令来完成它的服务。 Detais是here。但是，这不会为您提供任何访问控制。
您可以在本地安装gitosis并使用它来为您的存储库提供服务。这允许一个简单的访问控制系统，以便您可以限制/允许某些用户。

之前提出的相关问题可能是相关的。 git daemon为他工作 - Administrating a git repo without root permissions

我还发现了可能与您的问题相关的服务器故障 - https://serverfault.com/questions/21126/git-daemon-and-access-control-for-multiple-repos

Answer 5

可能不是最优雅的方式，但似乎有效

$ umask 0002
$ mv value.c value.c.tmp
$ cat value.c.tmp > value.c
$ rm value.c.tmp

有人可能会认为它可以防弹，但是有人带来了RPG ......

如果你们两个需要chmod，我想不出另一种方式 - 如果可以你可以chmod但是没有其他人，您可以在目录中chmod 6770 .或chmod g+s,u+s .（例如，设置SUID和GUID位），因此拥有该目录的人将始终是文件的所有者。不幸的是，有些（如果不是大多数），即EXT2 / 3/4忽略了SUID位。

当然，将umask设置为0002可以解决问题，而不是强制要求。

Answer 6

假设您的发布挂钩实际部署文件，而不是仅仅在工作副本中设置权限，您可以部署到临时位置，然后使用rsync确保文件内容和权限正确。

稍微好一些，但需要一些我猜不到的基础设施，就是确保部署脚本只在一个用户下运行。您可以使用sudo，如果您的系统管理员允许，或者通过设置git服务器服务（如gerrit），或者甚至通过每五分钟运行一次cron作业来检查更新并在必要时进行部署。

Answer 7

这可能有效：

touch $name.tmp
chmod 660 $name.tmp
cp $name $name.tmp
if cmp $name $name.tmp 2>/dev/null; then
    rm $name && \
        cp $name.tmp $name && \
        rm $name.tmp
fi

这只是您原始想法的变体

Answer 8

好的，基于以前的答案的混合物：

如果您将文件夹挂载到fstab，则可以设置文件夹的umask。如果您同意人们在该坐骑上工作，您可以强制执行g + w
如果您设置该文件夹的group-id位（g + s），则所有文件都属于该文件夹所属的组，因此该文件的组所有权将传播

可行吗？当然，强制执行挂载点并非易事。关于那个人的任何更好的想法吗？

如果我不拥有该文件但对目录有写权限，如何更改Unix权限？

8 个答案: