使用IIS应用池运行LibreOffice soffice.exe时临时文件创建权限问题

在IIS站点中以应用池（AppPool）身份运行LibreOffice的soffice.exe，将docx文件转换为pdf时，进程尝试在C:/Windows/LibreOffice目录创建临时文件，触发访问权限错误。切换为LocalSystem身份时可正常执行，且已为应用池授予相关业务文件夹（如D:\docs）的权限。

相关代码：

string libreOfficePath = @"C:\Program Files\LibreOffice\program\soffice.exe";
string docxPath = @"D:\docs\abc.docx";
string pdfOutputPath = @"D:\docs\out";
string logPath = @"D:\docs\logs";

string arguments = "--headless --convert-to pdf " + docxPath + " --outdir " + pdfOutputPath;

var startInfo = new ProcessStartInfo
{
    FileName = libreOfficePath,
    Arguments = arguments,
    RedirectStandardOutput = true,
    RedirectStandardError = true,
    UseShellExecute = false,
    CreateNoWindow = true,
    WorkingDirectory = @"C:\Program Files\LibreOffice\program"
};

实际执行的命令行：

"C:\Program Files\LibreOffice\program\soffice.exe" "--headless" "--convert-to" "pdf" "D:\docs\abc.docx" "--outdir" "D:\docs\out" "-env:OOO_CWD=2C:\\Program Files\\LibreOffice\\program"

• LibreOffice依赖用户配置文件存储临时数据
  LibreOffice运行时需要创建临时文件和保存配置，默认会使用当前用户的配置文件目录。但应用池默认身份（如ApplicationPoolIdentity）没有加载完整的用户配置文件，导致LibreOffice找不到合法的存储路径，只能 fallback 到系统目录（如C:\Windows\LibreOffice）尝试创建文件夹，而应用池身份没有该目录的写入权限。

• OOO_CWD环境变量格式异常
  从实际执行命令可以看到，-env:OOO_CWD参数值多了前缀2（正确应为C:\\Program Files\\LibreOffice\\program），这会导致LibreOffice无法识别正确的工作目录，进一步加剧了路径选择错误，触发系统目录写入尝试。该异常大概率是代码参数拼接或IIS环境变量传递时的编码/格式错误导致。

• 应用池身份的权限限制
  LocalSystem是系统级权限账号，拥有C:\Windows目录的写入权限，所以能正常执行；而应用池默认身份是受限用户，仅拥有指定业务文件夹的权限，无法写入系统目录，因此触发访问错误。

• 修复OOO_CWD参数：检查代码中参数拼接逻辑，移除异常前缀2，确保传递正确的工作目录参数。
• 启用应用池加载用户配置文件：在IIS应用池的高级设置中开启“加载用户配置文件”选项，让LibreOffice能使用应用池身份的专属配置目录存储临时文件。
• 手动指定LibreOffice配置目录：在启动参数中添加-env:UserInstallation=file:///D:/docs/libreoffice_config，指定一个应用池有权限写入的目录作为配置/临时文件存储路径（推荐此方案，符合最小权限原则）。
• 临时授予系统目录权限：若需快速验证，可给应用池身份分配C:\Windows\LibreOffice目录的写入权限，但不推荐长期使用，会带来安全风险。

内容的提问来源于stack exchange，提问作者João Gomes