这实际上是一个由三部分组成的问题,我将在下面解释,但问题是:
我有一个在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
所以我的问题,没有特别的顺序:
答案 0 :(得分:2)
<强> 1 强> 在gdb下正确调试setuid应用程序的唯一方法是以root身份运行gdb。为setuid应用程序执行此操作的最明智的方法是在应用程序启动后附加到应用程序。这样做的一个简单方法是在setuid应用程序中添加一行:
kill(getpid(), SIGSTOP);
这导致它在此时停止,然后使用:
附加gdbsudo gdb <application> <pid>
然后您将附加到应用程序并可以正常调试它。
2 sudo更改规则,因为它允许将当前用户环境中的各种项目导出到root用户的环境中。这完全取决于当前的sudo配置,并且可能会给你一个非常不同于setuid应用程序的环境,这就是为什么你需要依赖停止应用程序然后在运行时附加到它的技巧。
此外,应用程序中可能存在逻辑,用于检测它是否在setuid环境中运行,而在sudo下运行时实际情况并非如此 - 请记住sudo设置所有进程的id字段(真实uid,有效uid和已保存的uid)相同的值,setuid没有(真正的uid仍然是原始调用者的值)。您可以使用getresuid()调用来确定三个变量的状态。
3 问题是Permission Denied
邮件的前缀为sh:
;这似乎暗示正在尝试访问该文件的另一个子进程正在执行。在调用mkstemp之后,您可能希望放宽读取文件的权限,以便子进程能够读取该文件。