这实际上是一个由三部分组成的问题,我将在下面解释,但问题是：

>使用gdb,如何运行具有root权限的程序的一部分,其余的是正常的？
>为什么我会使用mkstemp在/ tmp中创建文件来获得“权限被拒绝”
        在setuid(到root)程序？
>为什么“sudo program_name”的执行方式与./program_name以及setuid到root的执行方式不同？

我有一个在Linux上运行的C程序(多个发行版),通常由具有正常权限的用户运行,但程序的某些部分必须以root权限运行.为此,我使用了set-UID标志,并且它可以正常工作.

但是,现在我想用普通用户权限调试程序,我发现我有一个catch-22.我刚刚添加了一个函数来创建一个临时文件(/ tmp / my_name-XXXXXX),并且该函数是从程序中的许多点调用的.无论出于何种原因,此函数在运行时发出以下消息：

sh: /tmp/my_name-hhnNuM: Permission denied

(当然,实际名称各不相同.)然而,该程序能够执行原始套接字功能,我绝对不知道root用户以外的用户无法完成. (如果我删除了setuid标志,程序就会失败.)

如果我通过没有sudo的gdb运行这个程序,它会死在原始套接字上(因为gdb显然不会 – 或者可能无法 – 尊重程序上的setuid标志).如果我在“sudo gdb”下运行它,那么一切正常.如果我将它作为“sudo ./my_name运行,一切正常.

这是该程序的ls -l输出：

-rwsr-xr-x 1 root root 48222 Jun 23 08:14 my_name

所以我的问题,没有特别的顺序：

>(How)我可以在gdb下使用不同的有效UID运行程序的不同部分吗？
>当./program将set-uid设置为root时,为什么“sudo ./program”与“./program”不同？
>为什么在setuid(到root)程序中由普通用户调用时mkstemp会失败？

最佳答案 1

在gdb下正确调试setuid应用程序的唯一方法是以root身份运行gdb.为setuid应用程序执行此操作的最明智的方法是在应用程序启动后附加到应用程序.这样做的一个简单方法是在setuid应用程序中添加一行：

kill(getpid(), SIGSTOP);

这导致它在此时停止,然后使用以下命令附加gdb：

sudo gdb <application> <pid>

然后,您将附加到应用程序并可以正常调试它.

2 sudo更改规则,因为它允许将当前用户环境中的各种项目导出到root用户的环境中.这完全取决于当前的sudo配置,并且可能使您的环境与setuid应用程序完全不同,这就是为什么您需要依赖停止应用程序然后在运行时附加到它的技巧.

此外,应用程序中可能存在逻辑,用于检测它是否在setuid环境中运行,而在sudo下运行时实际情况并非如此 – 请记住,sudo将所有进程的id字段(真实uid,有效uid和已保存的uid)设置为相同值,setuid没有(真正的uid仍然是原始调用者的那个).您可以使用getresuid()调用来确定三个变量的状态.

3问题是Permission Denied消息的前缀为sh：;这似乎暗示正在尝试访问该文件的另一个子进程正在执行.在调用mkstemp之后,您可能希望放宽读取文件的权限,以便子进程能够读取该文件.