☰

Fedora Core 升级后，二进制可执行文件上的 SETUID / SETGID 停止工作

tag-icon • tag-icon setuid setgid fedora
Fedora Core 升级后，二进制可执行文件上的 SETUID / SETGID 停止工作

我有一个 C 程序，需要访问一个充满内容的受保护目录。强文本这个想法是只有程序或管理员才有访问权限。

过去在 Linux 平台上，我已经相当成功地使用了文件系统 SETUID 和 SETGID 位。无论谁运行该程序，它都能正常运行，因为文件系统所说的 UID 和 GID 都是可执行文件的所有者。

或者更确切地说，它曾经成功运行过。

我不知道这个变化具体发生的时间，因为我只倾向于在出现硬件故障时更新操作系统，所以我会同时获得两个更新... 因此，鉴于跳过了许多版本，我只知道，截至目前，Fedora Core 17 上的开发系统不再遵守这些规定。由于 FC 19 是当前版本，我认为最新版本的情况只会更糟，而不是更好。

以下是‘ls -l’的输出：

-rwsrwsr-x 1 cu cu 26403 Aug 28  2012 comp

在调查解决方案时，我发现 chmod 的手册页这样说：

其他限制可能会导致 MODE 或 RFILE 的 set-user-ID 和 set-group-ID 位被忽略。此行为取决于底层 chmod 系统调用的策略和功能。如有疑问，请检查底层系统行为。

好的，但我不知道如何按照建议检查该策略和功能！他们没有提供任何帮助，只能使用 info 命令 - 但我发现那里没有任何帮助，只有有关新文件创建的默认用户和组所有权的数据。

SELINUX 已关闭。

问题：

  1. 在现代社会，什么才是做这种事的“正确”方式？

  2. 我如何检查政策并修改它们？

谢谢您的任何意见。

更多数据：

C 程序只有这一行分支来输出错误——摘录：

  line=malloc(large);
  if (!line) printf("virtual memory exhausted\n");
  if (line && FileExists(filename))
  {
     if (access(filename,R_OK)==0)
     {
        cfile=fopen(filename, "r");

答案1

您遇到的问题在于使用access()。

该man 2 access页面显示：

  The check is done using the calling process's real UID and GID,  rather
  than the effective IDs as is done when actually attempting an operation
  (e.g., open(2)) on the file.  This allows set-user-ID programs to  eas‐
  ily determine the invoking user's authority.

当你使用 setuid 二进制文件运行时你只需要更改你的有效的UID 不是你的真实 UID。因此access()调用将始终失败。

您应该删除access()。在这种情况下它是多余的，因为无论如何您都会使用 fopen 来打开文件，执行这样的访问检查然后对其进行读取也是有风险的。

相关内容