使用 C++ 以管理员/root 身份打开/写入文件（UAC/gksudo/等）
我正在开发的应用程序需要能够跨 Linux、OSX 和 Windows [Vista] 编辑某些受保护的文件。通常，当应用程序需要以提升的权限执行某些操作时，会出现一个密码请求对话框，要求用户验证是否允许应用程序以管理员身份执行这些操作。
我相信一般来说，Windows Vista 使用清单文件，OSX 有授权库（https://developer.apple.com/mac/library/documentation/Security/Reference/authorization_ref/Reference/reference.html），Linux 有多种 sudo 前端。
是否有普遍接受的跨平台方式来处理这个问题？我不希望我的应用程序必须以 root 用户身份运行，但我确实希望它能够打开受保护的文件进行读/写操作，然后恢复到正常用户模式。
The application I'm working on requires the ability to edit certain protected files across Linux, OSX, and Windows [Vista]. Generally, when an application needs to do something with elevated privileges, a password request dialog appears asking the user to verify they want to allow the application to perform those operations as an administrator.
I believe in general, Windows Vista utilizes Manifest files, OSX has the Authorization library (https://developer.apple.com/mac/library/documentation/Security/Reference/authorization_ref/Reference/reference.html), and Linux has a variety of sudo frontends.
Is there a generally acceptable cross-platform way of handling this? I don't want my application to have to be run as the root user, but I do want it to be able to open a protected file for read/write operations, then resume back to normal user mode.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
对于 Windows Vista，您基本上需要一个专用进程来执行管理操作。正如您所提到的，启用管理的进程将需要一个清单来指定请求的执行级别（请参阅此 MSDN 文章 了解详细信息）。
如果您仔细观察任何以非提升方式启动并支持“提升”本身的 Windows 应用程序，您会发现一旦需要管理权限，它实际上会打开一个全新的进程（例如，在启用 UAC 时转到任务管理器，单击“显示所有用户的进程”并注意它如何以管理员权限重新打开）。
因此，对于 Windows，您可能需要的架构需要两个进程：一个用于完成大部分工作的标准进程，以及一个用于调用以执行管理操作的管理进程。这两个进程需要通过某种安全方式进行通信（可能是 安全命名管道），以便可以代表标准流程完成管理工作。
这种方法可以在其他平台上推广，并且也许可以在某种类/接口中进行抽象，以便特定于平台的细节不需要泄漏。
For Windows Vista, you basically need a dedicated process to do administrative actions. As you mention, the admin-enabled process will need a manifest to specify the requested execution level (see this MSDN article for details).
If you look closely at any Windows application that starts non-elevated and supports "elevating" itself, you'll see that it actually opens a whole new process once administrative privileges are needed (e.g. go to Task Manager when UAC is enabled, click "Show processes from all users" and note how it reopens with admin privileges).
So for Windows, the architecture you probably need would require two processes: a standard process to do most of the work, and an admin process to call into to do the admin operations. The two processes would need to communicate via some secure means (perhaps a secure named pipe) so that admin work could be done on behalf of the standard process.
This approach may be generalizable across other platforms, and perhaps could be abstracted in some sort of class/interface so that platform-specific details would not need to leak through.