我有一个 GitLab Runner，我的同事很担心命令，比如
- 删除项目 $SOME_FOLDER* -Recurse -Force
可能很危险。例如，如果 GitLab Runnier 具有管理员权限，那么意外运行此命令可能会导致坏事发生☢️：
- 删除项目 C:\* -Recurse -Force
为了解决这个问题，我创建了一个本地服务帐户。出于这个问题的目的，我们可以假设该帐户名为 my_service_account。我没有将 my_service_account 分配给任何组。事实上，我什至没有将它分配给用户组。然后我给了 my_service_account 部署目录的完全控制权。
不幸的是，虽然 my_service_account似乎确实阻止了 GitLab Runner 使用如下命令来攻击整个主机系统：
- 删除项目 C:\* -Recurse -Force
它似乎并没有阻止 GitLab Runner 做这样的愚蠢事情：
- 回声“测试”> c:\someExistingDir\someNewGarbageFile.txt
我的导师和我对此进行了一些研究，我们发现我们可以通过将拒绝类型应用于我们想要保护的所有目录的 FULL CONTROL 基本权限来防止 GitLab Runner 创建随机文件。不幸的是，我们希望保护整个系统不受此影响，并且只允许 GitLab Runner 写入部署目录。
所以我尝试将拒绝类型应用于整个 C: 驱动器上的 FULL CONTROL 基本权限，但是当我开始使用 MS Windows GUI 来执行此操作时，它似乎想要覆盖一堆其他用户和组的权限像管理员、系统、用户和经过身份验证的用户（见图）：
在不使用可能导致“附带损害”的上述 GUI 的情况下，我拒绝访问 my_service_account 的所有系统文件的最简单和最安全的方法是什么？
注意：GUI 图片实际上来自我的家用 PC，而不是托管 GitLab Runner 的机器。提供图片是为了说明 GUI 坚持我更改 IMO 超出范围的用户和组的权限的问题。
您要确保正在运行服务的用户帐户或可以运行命令的上下文没有系统的本地管理员权限。
当您在“ ”
deny级别设置新的 NTFS“ ”规则时，您无法真正保护任何子文件和文件夹，除非您从您正在设置新拒绝规则的父对象中“ ”。C:\Replace all child object permission entries with inheritable permission entries~您在父级别设置的内容需要被继承并传播到所有子对象，以便这些权限限制也对子对象生效。
另请注意，即使选中该选项并允许任何新的 NTFS 限制性权限传播到子对象，也不会影响任何明确取消设置或破坏继承的文件夹或文件。
为了简单起见，我会确保服务帐户没有对系统的本地管理员访问权限，具有良好的系统备份和还原/恢复过程，并测试正在运行的命令以尝试破坏它。