答案 0 :(得分：2)
如果在解析其真实路径并检查其安全性后为$PQRHOME写入新值，则选项2有效。这样，您的代码很少需要在此后进行更改。
至于保留setuid权限，如果你可以进行某种特权分离，那么任何涉及真实用户输入的操作都会在真实的uid下运行。然后，特权进程和真实进程使用socketpair或类似的东西进行对话。
答案 1 :(得分：1)
嗯，听起来偏执，但是否存在取决于你的应用程序运行在哪个系统以及攻击者可以造成哪些损害。
因此，如果您的用户群可能存在敌意，并且损坏可能非常高，我会选择选项4，但修改如下以消除其缺点。
让我引用两个相关的事情：
1）
程序当前检查$ PQRHOME和关键目录 根据它是“安全的”（由pqrusr拥有， 属于pqrgrp，没有公开 写访问）。
2）
此后，程序通过完整访问$ PQRHOME下的文件 环境变量的价值。
您不需要实际硬编码完整路径，您可以硬编码从1）中提到的“程序”到文件所在的2）中提到的路径的相对路径。
要控制的问题：
a）你必须确保在可执行文件的路径和文件的路径之间没有任何“攻击者可访问的”（例如在符号链接方面）
b）你必须确保可执行文件以可靠的方式检查它自己的路径，但这不应该是我所知道的所有Unix中的问题（但我不知道所有的'我和我不知道'完全了解窗户。）在第3次评论后编辑：
如果您的操作系统支持/ proc，则syslink / proc / $ {pid} / exe是解决b）的最佳方式。
睡觉后编辑：
安装是否是“安全”过程？如果是这样，您可以创建（在安装时）包装器脚本。此脚本应该是可执行的但不可写（并且可能无法读取）。它会将$ PQRHOME env var设置为“安全”值，然后调用您的实际程序（它最终可能会执行其他有用的操作）。因为在UNIX中，正在运行的进程的env变量不能除了运行进程之外的其他任何东西都会被更改，所以你是安全的（当然env变种可以被父变更之前流程开始）。不过，我不知道这种方法是否适用于Windows。