【问题标题】:Unix suid bit problemUnix suid 位问题
【发布时间】:2010-01-04 23:47:51
【问题描述】:

我用 c 编写了一个程序,它进行一些计算然后创建一个文件夹。该文件夹的所有者是根用户。我正在尝试与其他用户一起运行此 c 应用程序。我遇到了这个错误:

mkdir: lol: Permission denied

好的,我知道这个错误是可以的,因为我没有权限,但是我在互联网上看到,如果我在文件上设置了 suid 位,那么这个文件将以所有者的权限运行. 我用过这个命令:

chmod +s filename

但它不起作用...... :(有什么想法吗?

编辑:
所以,首先,我的 Unix 发行版是 Mac OS X 10.5.8。我的文件名是 a.out,因为我是从 ic.c 用命令编译它的:gcc ic.c 我正在使用 root 用户运行 chmod 命令。

【问题讨论】:

  • 您是否以 root 身份运行 chmod
  • root 是二进制文件的所有者吗?不过,真的,重新考虑你的问题,问问自己是否真的需要 setuid 位。

标签: c unix


【解决方案1】:

我认为你还需要在你的程序中 setuid(0); 成为 root。只设置 s-bit 是不够的。

我同意所有其他人的观点,做所有这些事情是非常冒险的......

编辑

Jonathan Leffler 在 cmets 中是正确的。在这种情况下,setuid(0); 可能不需要。即在/etc下创建文件的必要步骤

create_file_under_etc.c

#include <stdio.h>
int main() {
  FILE *fp = fopen("/etc/so-su-test.txt", "wt");
  if (fp) {
    fprintf(fp, "I'll be back\n");
    fclose(fp);
    printf("File created.\n");
  } else {
    printf("File not created.\n");
  }
  return 0;
}

...以及测试和编译

cc create_file_under_etc.c
sudo chmod +s a.out
sudo chown root:staff a.out
./a.out

...你最好也清理一下

sudo rm a.out
sudo rm /etc/so-su-test.txt

【讨论】:

  • 是的,这是有风险的,我知道,但我想要这个,因为我需要向某人展示这个安全漏洞。
  • 有时需要使用 setuid(0) - 但在这种情况下可能不需要。关键是在可执行文件上设置 SUID 位。 setuid(0); call 将真实和有效(和保存的)UID 都设置为 0,root。启动该过程的用户没有太多痕迹。这样做很危险。
  • @JonathanLeffler 在哪些情况下有必要的?我遇到了一个调用其他程序(通过 system())的程序的问题,该程序不是使用 set uid 运行的,而是使用原始程序运行的。还有其他情况吗?
  • @Creshal:除非 SUID 程序 P1(例如,SUID 0)运行另一个程序 SUID 程序 P2(例如,SUID 4),否则您应该没有问题,但是您希望 P2 考虑该根( 0) 运行 P2。通常,如果一个 SUID 程序运行另一个程序,则第二个程序将使用运行第一个程序的人的真实 UID 运行。如果你想让第二个认为真正的 UID 是第一个的 SUID,那么你需要在 P1 上设置真正的 UID(可能在 fork 之后但在 exec 之前,在这种情况下你不能使用 system() after全部),并且setuid(0); 将是必要的。否则,AFAIK,不需要(但很方便)。
  • 除了sudo chown root,我什么都做了。这解决了我的问题。 +1
【解决方案2】:

好吧,你没有说“文件名”是什么。您只能对可执行文件执行 suid。特别是你不能在 shell 脚本上设置它——它必须是一个真正的机器代码可执行文件。而在现代 UNIX 中,比如一些可怕的 Linux 发行版,您可能根本无法设置它,除非跳过比您想的更多的障碍。

【讨论】:

  • 首先,我的 Unix 发行版是 Mac OS X 10.5.8。我的文件名是 a.out,因为我是使用以下命令从 ic.c 编译的:gcc ic.c
  • 对不起 Mac OS != U​​NIX 在我的书中。我能给你的任何帮助都到此为止。
  • @Infinity 刚刚意识到这听起来有点粗鲁 - 不是故意的,只是 Mac OS 与 UNIX 相距甚远,而且我知道 zip。
  • Mac OS 在这个级别上基本上是 FreeBSD ......而且它实际上是一个真正的 Unix,不像 Linux。但是,是的,它在某些方面非常不寻常,尤其是链接器。无论如何,就基本安全语义而言,它非常忠实于 POSIX。
  • 作为一个只需要使用终端窗口 ps 来处理停滞的进程(Yahoo Messenger)并在其上使用 kill 命令的人......我可以确认 MacOS X 是 UNIX .它将一些东西放在文件系统中一些非常奇怪的地方。但它仍然是 UNIX。
【解决方案3】:

尝试以 root 用户身份运行 chmod。

我过去一直被这个咬过:(

【讨论】:

  • 是的,我正在以 root 身份运行 chmod。
【解决方案4】:

语法不正确。命令必须像 chmod u+s 文件名一样锁定 chmod http://en.clihelper.com/chmod/ 的向导可以帮助了解 chmod 的语法

【讨论】:

  • 你有有趣的工具@user3875999。
【解决方案5】:

从您的问题中不清楚“文件名”到底指的是什么 - 可执行文件, 还是您要在其中创建文件的目录?做你想做的事,你需要使用 可执行文件上的chmod +s 命令,因此它将以root 权限运行。目标目录上的chmod +s 不会对非root 用户开放文件创建权限。

不过,整个概念让我觉得有点安全风险——不是更好吗 让 root 为这个应用程序在某个地方创建一个目录,然后 chmod 775 或 777 分别授予“组”或“世界”的写入权限?

编辑:我看到您确实在尝试 chmod 可执行文件,并且您正在运行 chmod 命令作为 root。但是 root 是否拥有可执行文件?你可能需要一个“chown” 除了 chmod +s 命令之外的命令(以 root 身份),以确保它运行 setuid root 而不是 setuid whoever-built-the-executable.

【讨论】:

  • 所以我在我的可执行文件上设置了 +s 位。还在源代码中使用了 setuid(0) 命令。并且正在按我的意愿工作。顺便说一句,我正在尝试重现一个安全漏洞,因为我需要将它呈现给某人。再次感谢!
  • 是的,root 用户拥有可执行文件。
【解决方案6】:

你使用了命令

chmod +s filename

您用于发出该命令的语法不正确。正确的语法是

chmod [ugoa]+s filename

您可以使用字母 u、g、o 和 a 的任意组合。

如您所知,Unix 存储有关每个文件夹/文件的权限信息。每个文件都有读取、写入、执行、粘贴等权限。对于单个文件,所有者、组和其他所有人都有一组不同的权限。因此,虽然文件的所有者可能能够读取、写入和执行文件,但所有者组中的所有其他用户可能只能读取该文件,而其他所有人可能根本无法访问该文件.

发出 chmod 命令时,您需要指定要更改权限的用户集。通过使用字母 u、g、o 和 a 的组合来做到这一点。 “u”更改文件所有者的权限,“g”更改所有者组中的所有用户,“o”更改所有者组之外的所有其他用户,“a”更改所有三组用户。

例子:

chmod ga-r confidential.txt 将使只有文件的所有者才能读取“confidential.txt”。所有其他用户,包括所有者组中的用户,将无法读取“confidential.txt”

chmod ga-rwx really_confidential.txt 将使除该文件所有者之外的任何人都无法读取、写入或执行“really_confidential.txt”。换句话说,您正在删除除所有者之外的所有用户读取、写入或执行“really_confidential.txt”的能力。

chmod u+s filename 将粘性位添加到“文件名”,仅供该文件的所有者使用。

编辑:哦,是的,由于该文件归根用户所有,因此请确保在您发出的命令前加上“sudo”。但看起来你已经知道了。

【讨论】:

  • 实际上,[ugoa](又名 who)部分对于 chmod 是可选的。未给出将设置/重置 +/- 权限的所有可能位。
  • 好吧。显示我知道多少。谢谢。
  • 我现在不在家,等我回家我会试试的。有趣的是你写了什么。
猜你喜欢
  • 2011-09-19
  • 2013-04-08
  • 1970-01-01
  • 2018-04-06
  • 1970-01-01
  • 2013-02-28
  • 2011-04-24
  • 2016-03-28
  • 2018-02-19
相关资源
最近更新 更多