当我不拥有该文件但对该目录具有写权限时，如何更改 Unix 权限？
我正在与一位同事共享一个 git 存储库，并且因为 git 不会传播完整的 Unix 文件权限，所以我们有一个在更新时运行的“钩子”，它根据需要设置“其他”权限。问题？该挂钩使用 chmod，事实证明，当我的同事提交文件时，他拥有该文件，因此我无法对其运行 chmod，反之亦然。这些目录都是组可写的、粘性的，所以我相信我们任何一个都有权删除任何文件并将其替换为相同名称、相同内容但不同所有权的文件。想必我们可以chmod它。但这似乎是一把非常大的锤子，我有点担心会把它搞砸。所以，有两个问题：
有人能想到另一种方法吗？
如果不是，那么实现“让这个文件属于我”的 bulletproof 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不仅可以协调更改，还可以将存储库发布为课程网站。发布网站是存储库的主要目的。权限脚本使用 git hook 在每次更新时运行，它确保学生无权阅读尚未公布的解决方案。请不要暗示我的 umask 错误。并非存储库中的所有文件都应具有相同的权限，无论选择什么 umask，某些文件的权限都需要更改。更不用说将我的 umask 偏好强加给我的同事是不礼貌的。
更新：我刚刚了解到，在我们的环境中，在我们有权访问的所有计算机上，root 都被取消为
nobody，因此依赖 root 的解决方案权限不起作用。
I'm sharing a git repository with a colleague, and because git does not propagate the full panoply of Unix file permissions, we have a "hook" that runs on update which sets the 'other' permissions as they need to be set. The problem? The hook uses chmod, and it turns out that when my colleague commits a file, he owns it, so I can't run chmod on it, and vice versa. The directories are all group writable, sticky, so I believe that either of us has the right to remove any file and replace it with one of the same name, same contents, but different ownership. Presumably then we could chmod it. But this seems like an awfully big hammer, and I'm a bit leery of screwing it up. So, two questions:
Can anybody think of another way to do it?
If not, what's the best design for a bulletproof shell script that implements "make this file belong to me"? No cross-filesystem moves, etc etc...
For those who may not have realized, write permission does not confer permission to 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
We are both in the ta105 group.
Notes:
We're using
gitnot only to coordinate changes but to publish the repo as a course web site. Publishing the web site is the primary purpose of the repo. The permissions script runs at every update using a git hook, and it ensures that students do not have permission to read solutions that have not yet been unveiled.Please do not suggest that I have the wrong umask. Not all files in the repo should have the same permissions, and whatever umask is chosen, permissions on some files will need to be changed. Not to mention that it would be discourteous for me to impose my umask preferences on my colleagues.
UPDATE: I've just learned that in our environment, root is quashed to
nobodyon all machines we have access to, so that a solution which relies on root privileges won't work.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
也许不是最优雅的方式，但它似乎有效
有人可能会说它可以防弹，但随后有人带来了角色扮演游戏......
如果两个你们需要 chmod，我想不出其他方法 - 如果你可以
chmod但其他人不行，你可以chmod 6770 。 或chmod g+s,u+s .在目录中（例如设置 SUID 和 GUID 位），因此拥有该目录的人将始终是文件的所有者。不幸的是，有些（如果不是大多数），即 EXT2/3/4 忽略了 SUID 位。当然，将 umask 设置为 0002 可以通过不强制设置来解决问题。
Probably not the most elegant way, but it seems to work
one could argue that it could be made bulletproof, but then someone brings along a RPG...
If both of you need to chmod, I can not think of another way - if it is OK that YOU can
chmodbut no the other guy, you canchmod 6770 .orchmod g+s,u+s .in the directory (e.g. set SUID and GUID bits) so the one that owns the directory will always be the owner of the files. Unfortunately some (if not most), namely EXT2/3/4 ignore the SUID bit.Of course, setting the umask to 0002 will solve the problem by not making it mandatory.
假设您的发布挂钩实际部署文件，而不仅仅是在工作副本中设置权限，您可以部署到临时位置，然后使用 rsync 确保文件内容和权限正确。
稍微好一点，但需要一些我猜尚未到位的基础设施，以确保部署脚本仅在一个用户下运行。如果您的系统管理员允许，您可以使用 sudo 来完成此操作，或者通过设置 git 服务器服务（例如 gerrit），甚至每五分钟运行一次 cron 作业来检查更新并在必要时进行部署。
Assuming that your publishing hook actually deploy files, rather than just setting permissions in the working copy, you could deploy to a temporary location then use rsync to ensure that the file contents and permissions are correct.
Slightly nicer, but requiring some infrastructure which I'm guessing isn't in place, would be to ensure that the deploy script only runs under one user. You could do this using sudo, if your sysadmins allow, or by setting up a git server service, like gerrit, or even by having a cron job run every five minutes which checks for updates and deploys if necessary.
这可能有效：
这只是你最初想法的一个变体
This might work:
It's just a variation of your original idea
好的，这是基于先前答案的混合内容：
如果将文件夹挂载到 fstab，则可以设置文件夹的 umask。如果您同意人们在该挂载上工作，您可以强制执行 g+w
如果您设置该文件夹的组 ID 位 (g+s)，所有文件都将属于该文件夹所属的组，因此文件的组所有权传播
是否可行？当然，强制执行该挂载点并不是一件容易的事。有人有更好的想法吗？
Ok, a mixture of things that build on previous answers:
you can set the umask of a folder if you mount it at fstab. If you could agree with people to work on that mount, you could enforce g+w
If you set the group-id bit of that folder (g+s) all files will belong to the group the folder belongs to, so the group ownership of the file propagates
Is that doable? Of course enforcing that mount point is no easy task. Any better ideas around that one anyone?
至少在一种 Unix 中，我发现了一种方法可以授予某人对特定组拥有的所有文件的
chmod和chown权限。这有时称为“组超级用户”或类似的名称。我确信我见过的唯一 Unix 版本是 Encore Multimax 跑了。
我进行了一些搜索，虽然我记得一些关于 Linux 中此类功能的模糊参考，但我一直无法找到它们。所以这可能不是一个选择。幸运的是，它可以被模拟，尽管模拟有点危险。
模拟这种情况的方法是创建一个非常具体的 suid 程序，在检查您是否是拥有该文件的同一组的成员后，该程序将作为 root 执行
chmod，并且您的用户名在特殊的/etc/chmod_group文件中被列为具有该权限，该文件必须由 root 所有，并且只能由 root 读写>。There is at least one Unix in which I've seen a way to give someone
chmodandchownpermissions on all files owned by a particular group. This is sometimes called "group superuser" or something similar.The only Unix I'm positive I've seen this on was the version of Unix that the Encore Multimax ran.
I've searched a bit, and while I remember a few vague references to an ability of this sort in Linux, I have been unable to find them. So this may not be an option. Luckily, it can be simulated, albeit the simulation is a bit dangerous.
The way to simulate this is to make a very specific suid program that will do the
chmodas root after checking that you are a member of the same group as owns the file, and your username is listed as having that permission in a special/etc/chmod_groupfile that must be owned by root and readable and writeable only by root.最直接的方法是让您的合作伙伴和您成为一个新组的成员（假设为“devel”），并将其作为文件的组。这样一来，它就可以归你们任何一个人所有，只要这个团体是正确的，你们就可以使用它。
如果这对您不起作用，可以配置“sudo”，以便只有这两个用户可以以 root 身份（无需密码）对该特定目录中的文件运行 chmod 命令。
The most straightforward way to do this is to make your partner and you members of a new group (let's say "devel"), and have that as the group of the file. That way it can be owned by either of you, and as long as the group is right, you can both work with it.
If that doesn't work with you, "sudo" can be configured such that only those two users can run a chmod command on files in that specific directory as root with no password.
如果您正确设置
umask，则可以使用以下命令创建文件首先正确的权限：If you set your
umaskcorrectly, the files could be created with the correct permissions in the first place:我要退后一步。如果我违反了您系统中的某些我尚未阅读的限制，请告诉我。
从你的问题来看，我假设你正在尝试使用
file://URL 共享 git 存储库，并依赖 UNIX 文件系统权限来处理授权等。为什么不考虑另一种方式分享你的存储库，不涉及这个麻烦？我可以想到两种方法。
不久前出现了一个可能相关的相关问题。
git daemon为他工作 - 管理没有 root 权限的 git 存储库我还发现了一些可能与您的问题相关的服务器故障 - https://serverfault.com/questions/21126/git-daemon-and-access-control-for-multiple-repos
I'm taking a step back. Let me know if I'm violating some restriction in your system I haven't read.
From your question, I assume you're trying to share a git repository using
file://URLs and relying on the UNIX filesystem permissions to take care of authorisation etc. Why don't you consider another way to share your repositories that doesn't involve this hassle?I can think of two ways.
git daemoncommand. Detais are here. This will however not give you any access control.There was a related question that came up a while ago that might be relevant.
git daemonworked for him - Administrating a git repo without root permissionsI also found something on server fault that might be relevant to your problem - https://serverfault.com/questions/21126/git-daemon-and-access-control-for-multiple-repos