如何在 Linux 中设置权限，以便两个用户可以更新服务器上的同一个 SVN 工作副本？

Question

我的服务器同时安装了 Subversion 和 Apache，并且 Apache Web 目录也是 Subversion 工作副本。这样做的原因是简单的命令 svn update /server/staging 将把最新的源部署到登台服务器。

Apache 公共 Web 目录： /server/staging —（这是 SVN 工作副本。）

我的服务器上有两个用户，“richard”和“austin”。他们都是“开发者”群体的成员。我使用“sudo chown -R richard:developers /server”将 /server 目录的权限递归设置为 richard:developers。

然后，我为“richard”和“开发人员”组设置读取、写入和执行的权限。

所以可以肯定的是，“奥斯汀”现在应该能够使用 svn update /server/staging 命令？然而，当他尝试时，他得到了错误：

svn: Can't open file '/server/staging/.svn/lock': Permission denied

如果我递归地将 /server 的所有者更改为 austin:developers，他可以很好地运行该命令，但“richard”则不能。

我该如何解决这个问题？我想创建一个提交后挂钩，以便在提交文件时自动部署暂存站点，但我看不到一种对两个用户都适用的方法。钩子是：

/usr/bin/svn update /server/staging

对它们两个使用相同的用户帐户实际上并不是一个可接受的解决方案，而且我不知道有什么方法可以以“root”身份运行挂钩内的命令。

任何帮助表示赞赏！

Answer 1

目录集组ID

如果设置了目录条目上的setgid位，则该目录中的文件将具有组所有权作为目录，而不是创建该文件的用户组。

当多个用户需要访问某些文件时，此属性很有用。如果用户在设置了setgid属性的目录中工作，则任何用户在目录中创建的任何文件都将具有该组的权限。例如，管理员可以创建一个名为spcprj的组，并将用户Kathy和Mark添加到组spcprj中。可以使用设置的GID位和Kathy和Mark创建目录spcprjdir，尽管在不同的主组中可以在目录中工作并且可以完全访问该目录中的所有文件，但仍然无法访问彼此主要组中的文件

以下命令将在目录上设置GID位：

chmod g+s spcprjdir

目录“spcprjdir”的目录列表：

drwxrwsr-x 2 kathy spcprj 1674 Sep 17 1999 spcprjdir

代替组权限中的执行位的“s”导致写入目录“spcprjdir”的所有文件。属于组“spcprj” 。

编辑：来源= Linux文件和文件权限

Answer 2

我将使用 svn：// 协议设置 svnserve ，这是一个简单的Subversion服务器。您可以对其进行设置，使其在自己的用户帐户下运行，然后只有该用户才能访问该存储库。然后，该用户可以拥有在提交后挂钩上运行 svn update / server / staging 的正确权限。

Answer 3

在您的 svn 存储库中，您可以找到一个用于设置权限的“conf”目录。你那里有 3 个文件：

• 授权
• 密码
• svnserve.conf

您可以在 authz 文件中设置哪些用户拥有哪种访问权限（每个用户或每个组）。你在那里设置组，SVN组而不是linux用户组（散列线是注释）：

[groups]
# harry_and_sally = harry,sally
projectgroup = richard,austin

# [/foo/bar]
# harry = rw  -- user harry has read/write access
# * =  -- everybody have no access

# [repository:/baz/fuz]
# @harry_and_sally = rw  -- harry_and_sally group members have read/write access
# * = r  -- everyone has read access

[/server/staging]
@projectgroup = rw
* = r

解决这个例子并设置你的配置。在“passwd”文件中设置用户密码。执行

cat passwd

您将收到带注释的文件，其中包含如何设置的说明。

Answer 4

我使用WebDAV - 所有SVN更新和提交都是通过apache处理的，我从来没有遇到过这样的问题。