如何限制Atlassian Bamboo版本中的文件系统访问？

我们在Ubuntu上运行了Atlassian Bamboo。当开发人员设置构建时，他或她就有可能运行Shell脚本任务。在正在构建的代码库上运行（自定义）命令很有用。

但是，运行的脚本也可以访问Bamboo工作目录（<Bamboo-home-dir>/xml-data/build-dir/JOB_KEY）中其作业目录之外的文件系统。因此，JOB_A也可以访问JOB_B：的文件cd ../JOB_B。

有可能限制这种访问吗？

PS我知道一个事实，即构建是由Bamboo中的（本地或远程）代理运行的，您可以由不同的代理构建不同的项目。但是，如果两个项目是由同一代理构建的，则这些项目可以访问彼此的文件。

当前尚无法限制能够在同一代理上运行的作业之间潜在的交互。有很多功能请求都要求这种粒度，但是如果我正确理解了您的问题，最合适的请求将是这张BAM-2504吉拉票证

这是产品线中的巨大缺口，我发现的唯一解决方案与上面链接的请求所建议的解决方案相似，从本质上讲，您的Bamboo流程需要以足够的特权运行，才能冒充代表项目的用户集。您想分开。

一旦有了这种机制，您只需要尝试强制所有计划作为不可模仿的帐户之一运行，例如取决于项目或创建者等。

问题在于当前存在的访问控制方式意味着很少有核心管理员需要设置所有计划，以便他们可以确定所需的权限分配，而不是让非管理用户编辑和创建自己的计划。

如果这种方法不可行（一旦您进入“数百个用户”类型的范围），这是不可行的，那么您真正能够做的唯一尝试来阻止构建作业彼此交互的唯一方法就是实施竹子给你的控制力很弱。

我尝试了两种方法来执行此操作：

1. 删除或削弱（从所有代理中删除所有功能）本地代理，对于每个不同的项目/团队/无论董事会上的竹子实例是什么，您都需要强制他们使用BYO构建服务器。在大多数情况下，与潜在的数据泄漏或恶意计划交互的成本相比，我所涉足的代理成本是微不足道的。
2. 确保在计划中确实包含或认为确实包含敏感数据的项目在构建后始终对其环境进行消毒。这将负担从管理工具的团队转移到了编写其计划的项目上，并迫使他们防御性地清理他们不希望别人使用的任何信息。

哪一种解决方案都无法达到完美，但是就我所知，如果有共享的竹子实例，则可以实现的最大分离程度。