C# 文件权限的最小权限原则 C#在服务中应如何配置最严格的文件访问权限

服务运行账户必须使用专用低权限用户，禁止localsystem或administrator；文件操作依赖账户实际权限，需显式授权目标路径并避免静默异常；禁用交互式api，预建目录并固化ntfs权限。

服务运行账户必须是专用低权限用户，不能用 LocalSystem 或 Administrator

windows 服务默认以 LocalSystem 运行时拥有近乎管理员级的文件访问能力，这直接违背最小权限原则。哪怕只读一个日志目录，也不该赋予它修改 C:Windows 或其他服务无关路径的权限。

实操建议：

• 新建专用本地用户（如 svc-filewatcher），不加入任何特权组（Administrators、Power Users 等）
• 在服务属性 → “登录”选项卡中显式指定该用户，并填入密码（服务账户密码需定期轮换）
• 若服务需网络访问（如写共享目录），改用域账户并限制其仅对目标 UNC 路径有 Read/Write 权限，而非给 Everyone 开放

DirectoryInfo 和 FileStream 构造时默认继承进程权限，不自动降权

C# 的 DirectoryInfo、FileStream、File.WriteAllText 等 API 不会因为你“想最小权限”就自动过滤掉高权限。它们完全依赖当前线程的 Windows 访问令牌 —— 也就是服务登录账户的实际权限。

常见错误现象：

• 开发机上用自己账号测试正常，部署到服务后抛出 UnauthorizedAccessException（账户没被授予目标目录的 Traverse 或 ReadData）
• 误以为 FileOptions.NoBuffering 或 FileAccess.Read 能绕过 NTFS 权限检查 —— 实际上这些参数只影响 I/O 行为，不改变 ACL 判定逻辑

实操建议：

• 用 cacls 或 icacls 显式检查目标路径权限：icacls "C:AppData" /user svc-filewatcher
• 只授予必要权限：对日志目录加 Modify，对配置目录只加 ReadAndExecute，绝不用 FullControl
• 避免使用 Directory.CreateDirectory 自动递归建目录 —— 它会尝试在父路径上写 ACL，而低权限账户通常无权修改父目录的 WRITE_DAC

App.config 中 fileStream 的 useLegacyEncoding=false 不影响权限，但影响日志写入失败静默

这个配置项常被误认为和安全相关，其实它只控制 StreamWriter 是否使用系统默认编码（如 GBK），与文件访问权限完全无关。但它会间接导致权限问题更难排查。

使用场景：

• 服务以低权限账户运行，尝试用 File.CreateText("C:Logspp.log") 写日志
• 若 C:Logs 目录未提前授权给该账户，CreateText 抛 UnauthorizedAccessException
• 但如果日志框架捕获异常后静默吞掉（尤其设置了 useLegacyEncoding="false" 后某些旧版 NLog 行为异常），你根本看不到错误，只发现日志缺失

实操建议：

• 所有文件操作必须包裹 try/catch (UnauthorizedAccessException) 并记录原始错误信息
• 启动服务前，用 runas /user:svc-filewatcher cmd.exe 手动模拟账户权限，测试能否 type 或 echo test > test.txt 目标路径
• 避免在服务启动阶段动态创建父目录；把 C:AppData、C:AppLogs 等路径预建好，并用 icacls 固化权限

Windows 服务无法绕过 UAC，但可以利用“服务隔离”特性规避交互式权限提升陷阱

有人试图让服务调用 Process.Start("notepad.exe") 并提权写系统目录 —— 这在 Vista+ 上必然失败。服务会话（session 0）与用户桌面（Session 1+）完全隔离，且 UAC 对服务账户默认禁用提权弹窗。

性能 / 兼容性影响：

• 不要在服务中调用需要交互或桌面会话的 API（如 ShellExecute、OpenFileDialog），它们要么失败要么挂起
• 如果真需触发用户侧动作（如通知用户配置变更），应通过命名管道或事件日志通信，由独立的用户模式代理程序处理，而非服务直写 HKEY_CURRENT_USER
• NTFS 权限检查本身开销极小，但频繁检查不存在的路径（如每秒 File.Exists(@"servershareconfig.json")）会因 SMB 超时拖慢服务响应

真正容易被忽略的是：服务账户对 C:WindowsTemp 默认只有 Read 权限，不是 Write。很多第三方库（如某些 xml 解析器）会在临时目录解压资源，结果静默失败。得手动给 svc-filewatcher 加 Write 权限到你指定的专用临时目录，而不是复用系统 Temp。