SVN权限问题

Posted 2023-04-15

网上看到的很多文章，都是对父目录有只读权限，子目录有读写权限。
子目录权限往往会继承父目录，就意味着对父目录至少要有读的权限，子目录才看的到。不管有没有父目录的read权限，能不能实现看不到父目录下其他的目录，只对自己目录有修改权限？
area
|---hangzhou--A--B
|----C----D
|----E-----F
area是库名，就是说hangzhou下面有A、C、E目录，B看不到CE和其子目录，只能是hangzhou--A--B，能修改B和B下的所有文件

对于B能不能 “看到”C、E目录，分两种环境来说：
1、使用浏览器访问area这个库时，如果B有hangzhou的读取权限，且没有C、E这两个文件夹的读取权限，就能看到hangzhou下有A、C、E这三个文件夹，但不能进一步查看C、E两个文件夹的内容；
2、使用客户端checkout出area这个库时，如果B有hangzhou的读取权限，且没有C、E这两个文件夹的读取权限，就只能checkout出hangzhou下的A这个文件夹，也就不会看到C、E两个文件夹。（但是如果用TortoiseSVN客户端自带的版本库浏览器，仍然可以看到存在C、E文件夹。）

所以如果你是想在checkout出来的内容中看不到C、E，可以很简单的实现，就是给B赋予hangzhou的只读权限，赋予A的读写权限，赋予C、E的无权限。
如果你是想让B无论任何都不知道C、E文件夹的存在，那就只能连hangzhou的只读权限都不给B，只给B赋予A的读写权限，告诉B他的访问地址就是A这个文件夹，完全不告诉他有area、hangzhou这两层文件夹的存在。 参考技术A 1、能修改二级目录中的内容
2、能修改三级目录中的内容（前提是你对三级目录“没设置权限”指的是没有专门指定三级目录的权限，而不是在三级目录的权限里设置“user = ”）

SVN的权限设置是底层自动继承上一层的权限，因此一般把通用的权限设置在高层，有区别的权限设置在下层

SVN 权限被拒绝 - txn-current-lock

【中文标题】SVN 权限被拒绝 - txn-current-lock

【英文标题】：SVN permission denied - txn-current-lock

【发布时间】：2012-01-17 12:58:24

【问题描述】：

我刚刚在我的 ubuntu 服务器上设置了 svn。我有一个可以登录的用户。问题是，每当我尝试更改文件结构时，我都会收到权限被拒绝错误。

无法打开文件“/var/www-svn/db/txn-current-lock”： 没有权限

我的仓库位于 /var/www-svn 中，并且该文件夹的权限是 drwxr-xr-x 用户和组 svn （我的权限不好，所以我不知道对不对）。我在 svn 上登录的用户在 svn 组中，但我无法更改文件结构。 我做错了什么？如果我将文件夹的用户和组更改为我也登录的用户，它会起作用。

在 svnserve.conf 中，anon-access 设置为 none 并且 auth-access 设置为 write.

（我通过在 /var 目录中输入 sudo chown -R svn:svn www-svn 更改了 /var/www-svn 的所有者。）

【问题讨论】：

你如何访问 repo（svn、http、文件等）？

svn（使用 TortoiseSVN 回购浏览器）。

那么您的访问/身份验证 (svnserve.conf) 配置是什么样的？

我已经更新了我的帖子。

你配置用户了吗？ svnbook.red-bean.com/en/1.0/svn-book.html#svn-ch-6-sect-3.2

【参考方案1】：

文件系统上的存储库文件夹必须由您的 svn 或 apache 通过 web-dav 正在处理的同一 linux 用户拥有或最终拥有读/写权限...

在我的情况下是：

$ chown -R www-data:www-data /svn/reponame

但在其他情况下，可能会有所不同，例如

$ chown -R someuser:somegroup /svn/reponame

所以用适当的值替换 someuser:somegroup。

【参考方案2】：

您必须为/var/www-svn/文件夹添加SETUID位，因为在事务下会有SVN运行期间生成的文件夹，用于保存由文件夹表示的事务。

简而言之就是做

chmod +s -R /var/www-svn/

应该能解决问题。

【参考方案3】：

svnserve 守护程序在我的用户下运行，而不是以 root 身份运行。我杀死了在我的用户下运行的 svnserve 进程并以 root 身份重新启动它。现在可以了。

【参考方案4】：

我的问题最终是我申请了权限，然后svnadmin create 又申请了，所以需要再次设置权限。

 $ sudo chown -R www-data:subversion myproject
 $ sudo chmod -R g+rws myproject

【参考方案5】：

这似乎是 superuser.com 的问题。 乍一看，组 svn 没有对该文件夹的写入权限。所以也许这就是问题所在。

链接已失效，请参阅 cmets 以获得快速解决方案 看看这个http://www.svnforum.org/threads/35493-Can-t-open-db-txn-current-lock-permission-denied

【讨论】：

试试：chmod -R 770 /var/www-svn/

找不到您提供的链接

@Zeeshan 谢谢，我已经添加了一个快速解决方案作为这个答案的第一条评论，希望没问题。我要编辑和删除链接

【参考方案6】：

如果您没有 sudo 权限：

在我的特殊情况下，我正在从一个共享的 Webfaction 服务器迁移到另一个。复制文件必须将整个存储库所有权分配给我的用户名，而所有者可能应该是 apache，以便可以访问存储库。我无法申请任何chown apache:mygroup repo，因为我无权访问用户 apache。如果没有 root 访问权限，使其工作的唯一方法是在我的存储库根目录中使用chmod -R 777 .，最终删除一个我无权 chown 的锁定文件。这终于解决了问题，我可以再次提交。

【参考方案7】：

创建的存储库缺少读写权限。

chcon -R -t httpd_sys_rw_content_t /path_to_svn 例如：chcon -R -t httpd_sys_rw_content_t /opt/svn/trunk

【讨论】：

在 CentOS 8 上通过 apache httpd 设置了 svn 时遇到了这个问题（使用了这个 guid：computingforgeeks.com/…）。这解决了这个问题。谢谢:)

【参考方案8】：

最后但同样重要的是，如果您的存储库由用户和组 svn 拥有

(sudo chown -R svn:svn /var/svn/repos)

请务必将可以访问它的用户添加到 svn 组。 vi /etc/group

svn:x:502:user1,user2

【参考方案9】：

虽然这个问题很老了，但它在 Google 上的排名更高，但在 Linux 上的 Apache / httpd 上使用 subversion 的问题没有找到有用的解决方案。

我在 Apache、CentOS linux 上运行颠覆。对我来说，问题是由于 SELinux 和禁用这对我有帮助。

在执行此操作之前需要谨慎，因为可能不建议在生产服务器上禁用 SELinux。请在尝试之前仔细阅读文档。

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Enabling_and_Disabling_SELinux-Disabling_SELinux.html

正如 Stewart 在评论中建议的那样，另一种解决方案是更新文件权限，尽管无法获得更多详细信息，但对文件权限进行一些调整应该会有所帮助。

【讨论】：

发布的链接已损坏。为什么你不能直接在这里发布答案？这就是为什么“仅链接答案”不受欢迎的原因。现在我们永远不会知道....

@Stewart 抱歉，链接已关闭。使用搜索引擎缓存或archive.org 似乎无法恢复。据我所知，SELinux 的问题已通过禁用它得到解决。尝试做同样的事情并告诉结果。在 PROD 服务器上执行此类操作之前，请谨慎阅读并仔细阅读。

我最终通过更改文件所有权解决了这个问题。

在 CentOS 上，而不是禁用完全不推荐的 SeLinux。尝试使用@Sadasiv 上面的修复。它对我有用

【参考方案10】：

重启 Eclipse IDE。

我遇到了完全相同的情况，但在尝试使用 EclipseIDE 提交更改时失败了。

在运行 Eclipse 时，我更改了喜欢提交到存储库的用户组。

令人惊讶的是，我注意到，一旦我重新启动 Eclipse，就会授予修改后的存储库组/权限。我认为 Eclipse 保持 ssh 通道打开，并且在 ssh 通道会话期间修改的组权限被忽略。

在 eclipse-restart 期间，ssh-session 被重新创建，修改后的组权限被粘贴到授予提交的新 ssh-session。