Subversion中基于路径的访问控制的替代方法 [英] Alternative to path based access control in Subversion

问题描述

Subversion中基于路径的访问控制是否可以替代?

Is there any alternative to path based access control in Subversion?

我正在处理一个包含文件的存储库，该文件受 ITAR .有几个团队可以访问该存储库，但是其中一些团队甚至不能查看 ITAR敏感数据，因此我们在这里谈论的是读取访问，而不仅仅是提交访问.

I'm dealing with a repository that contains files that are subject to ITAR. Several teams will have access to the repository, but some of them are not allowed to even see ITAR sensitive data, so we're talking about read access here, not just commit access.

现在我有几种选择可以解决这个问题.

Now I have several options for dealing with this.

第一个只是列出所有具有访问限制的文件.这样做的问题是，在将文件名添加到身份验证文件之前，我们需要知道文件名是什么.因此，开发人员创建了一个ITAR敏感文件，将完整路径通过电子邮件发送给svn管理员，然后svn管理员将其添加到auth文件中.只有这样，开发人员才能真正添加​​并提交文件.

The first is simply listing out all the files that have access restrictions. The problem with that is that we need to know what the filename is going to be before it can be added to the auth file. So a developer creates an ITAR sensitive file, e-mails the full path to the svn admin, who then adds it to the auth file. Only then can the developer actually add and commit the file.

另一种解决方案是在顶层具有两个目录，例如general和mil，并且具有相同的子目录.这样，所有敏感文件都进入mil，所有其他文件都进入general.这给了我一个简短而甜美的auth文件，但是缺点是，如果文件成为 ITAR敏感文件，则需要将其从一棵树移到另一棵树.我们可以解决这个问题，但这并不是最佳选择.

Another solution is to have two directories at the top level, say general and mil, with the same subdirectories. That way, all sensitive files go into mil and all others go into general. That gives me a short and sweet auth file, but the downside is that if a file becomes ITAR sensitive, it needs to be moved from one tree to the other. We can work with that, but it's not optimal.

我想 拥有的是基于属性的访问控制.如果我们可以仅向文件添加属性，例如说mil或itar:reason，然后基于该属性限制访问，那将是理想的选择.开发人员可以在首次提交之前或文件变得敏感时添加属性.但是，除非我错过了，否则不可能.

What I would like to have, is property based access control. If we could just add a property, say mil or itar:reason to a file and restrict access based on that, that would be ideal. Developers could add the property before first commit, or when a file becomes sensitive. However, except if I have missed it, that's not possible.

那么有人看到这个问题的其他解决方案了吗?

So does anyone see any other solution to this problem?

推荐答案

我不确定属性是否会成功，因为它们是版本控制的.因此，如果添加文件而忘记立即设置属性，那么聪明的用户可以检索该文件的早期版本.您必须愿意从转储文件中清除有问题的数据，这当然需要一些停机时间.

I'm not sure that even properties will do the trick, as they are versioned. So if you add a file and forget to set the property right away, a clever user could retrieve an earlier version of the file. You'd have to be willing to scrub the offending data from your dump file, which of course requires some down time.

无论如何，如果有人犯了一个错误并且将文件放置在错误的位置，错误的存储库或使用错误的属性，那么几乎所有解决方案都会遇到这个问题.如果您知道ITAR文件的某些属性，则可以编写一个钩子以防止将其放入存储库的错误部分.然后，您可以查看基于已知敏感"路径或什至是单独的存储库和外部文件的解决方案.

Anyway, that's a problem you'll hit with almost any solution if someone makes a mistake and puts a file in the wrong place, in the wrong repo, or with the wrong properties. If you know some property of the ITAR files then you could write a hook to prevent them being put into the wrong part of the repository. Then you can look at solutions based on 'known sensitive' paths or even separate repositories and externals.

否则，您可以考虑在Apache前面放置一个代理，该代理知道所有敏感文件(无论何时将它们指定为敏感文件)，并将其从未经授权的用户的流量中清除.这是一个棘手的问题.

Otherwise you can look at putting a proxy in front of Apache that knows all the sensitive files, regardless of when they were designated as sensitive, and scrubs them out of the traffic for unauthorized users. It's a tricky problem.

这篇关于Subversion中基于路径的访问控制的替代方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！