linux - 在Linux中，可执行文件的位置会影响setuid位的解释方式吗？

在Linux系统中，setuid程序所在目录的权限是否会影响内核启动进程的方式？我问的原因是，当我在两个不同的目录中编译相同的setuid程序时，实际上只假定了一个目录中的用户权限。我将其编译为/tmp和/home/flag03，其中flag03是我尝试获得访问权限的用户帐户。从/tmp执行时，它没有按预期升级特权，但在/home下工作。

有关此问题的一些背景:

我正在exploit-exercises.com/nebula的03级上工作。该练习要求您有权访问flag03用户帐户。练习是经过设置的，以便flag03用户定期运行cronjob，这将使您可以在特定目录中执行脚本。我的计划是编写一个简单的bash脚本，该脚本将编译本身启动bash shell的setuid程序，然后使用chmod +s设置setuid位。这个想法是，当编译setuid程序时，它是由用户flag03通过cronjob编译的。一旦执行了这个新编译的程序，它将以flag03用户身份启动一个shell，这就是目标。

这是简单的setuid程序(l3.c，基于级别1 + 2):

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>

int main(int argc, char **argv, char **envp)
{
  uid_t uid;
  gid_t gid;

  uid = geteuid();
  gid = getegid();

  setresuid(uid,uid,uid);
  setresgid(gid,gid,gid);
  printf("uid: %d\n", getuid());
  printf("gid: %d\n", getgid());
  system("/bin/bash");

  return 0;
}

为了使它起作用，bash脚本以用户flag03编译程序，然后对setuid位进行chmod设置。

#!/bin/bash

#gcc -o /tmp/l3 /tmp/l3.c
#chmod +s,a+rwx /tmp/l3
gcc -o /home/flag03/l3 /tmp/l3.c
chmod +s,a+rwx /home/flag03/l3

/tmp中生成的可执行文件未按预期升级特权，但是/home/flag03中生成的可执行文件按预期工作。

注意我刚刚创建了一个新的bash脚本，以将在/tmp中编译的setuid程序的版本移动到/home/flag03，然后重置setuid位。从那里执行时，该版本也能正常工作。因此在我看来，setuid程序所在目录的权限对启动过程有某种影响。也许这与/tmp有点“特殊”目录有关？

感谢您对此问题的关注!

最佳答案

如果使用nosuid选项挂载了文件系统，则执行位于此处的文件时，suid位将被忽略。据我了解，/tmp通常是使用tmpfs选项安装的独立文件系统(通常为nosuid)。这种配置的动机是防止除了/tmp(例如nobody)外没有可写存储的帐户遭到破坏，无法生成suid二进制文件，该文件可用于某些精心设计的多步攻击中以提升特权。

关于linux - 在Linux中，可执行文件的位置会影响setuid位的解释方式吗？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/15377110/