我有一个 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 做这样的蠢事：
- echo“测试”> c：\ someExistingDir \ someNewGarbageFile.txt
我和我的导师对此进行了一些研究，我们发现，我们可以通过应用否定对所有我们要保护的目录输入 FULL CONTROL 基本权限。不幸的是，我们想保护整个系统免受这种影响，仅有的允许 GitLab Runner 写入部署目录。
所以我尝试应用否定输入对整个 C: 驱动器的 FULL CONTROL 基本权限，但当我开始使用 MS Windows GUI 执行此操作时，它似乎想要覆盖一堆其他用户和组，如管理员、系统、用户和经过身份验证的用户（见图）：
对我来说，拒绝访问的最简单、最安全的方法是什么全部不使用上述 GUI 来窃取 my_service_account 的系统文件，这可能会导致“附带损害”？
注意：GUI 图片实际上来自我的家用电脑，不是托管 GitLab Runner 的机器。提供该图片是为了说明问题，其中 GUI 坚持要求我更改超出范围的用户和组的权限。
答案1
对我来说，拒绝访问所有系统文件的最简单、最安全的方法是什么......
您要确保运行该服务的用户帐户或可以运行该命令的上下文没有系统的本地管理员权限。
我不想更改这些用户的子文件夹权限...
当你设置新的 NTFS “deny“统治”C:\“级别，你无法真正保护任何下面的子文件和文件夹，除非你“Replace all child object permission entries with inheritable permission entries~“从您正在设置新的拒绝规则的父对象。
您在父级别设置的内容需要被继承并传播到所有子对象，以便这些权限限制也对子对象生效。
还请注意，即使选中该选项并允许任何新的 NTFS 限制权限传播到子对象也不会影响任何明确未设置或损坏继承的文件夹或文件。
保持简单，我会确保服务帐户没有系统的本地管理员访问权限，有良好的系统备份和恢复/恢复过程，并测试运行命令以尝试破坏它。