问题标签 [setuid]

我有一个 UNIX 守护进程，它等待 SIGHUP 刷新数据。我尝试通过 Proc::Killall ("killall('HUP', 'mydaemon');") 从 Perl 脚本（在同一服务器上的 Apache www-data:www-data 下）发送信号，但我没有适当的权限。suid bit 也不起作用。来自 shell 的“kill -n HUP”正在工作。

你有什么想法吗？

为什么这个使用 os.setuid()/gid() 的简单程序会失败？是用 python 编写的，但我认为这不是与语言相关的问题（最后都是相同的 posix 系统调用）：

它返回此异常：

错误是什么？

我正在尝试编写一个程序并将其与使用 Gtk+ 构建的 gui 集成。然而，将由 gui 调用的 exe 设置了 setuid 位。但是 gtk 不允许此 exe 按照 gtk 社区的规定运行。然而，他们说我们必须编写单独的帮助程序等等。我真的不明白那是什么意思。任何人都可以请阐明如何克服这个问题？我真的需要立即解决。

我有一个通过 Apache 或命令行调用的 Perl 脚本。

出于测试目的，我将我希望 Perl 脚本操作的用户名传递给它，并用于POSIX::setuid设置uid.

如果我从命令行运行脚本，则uid设置正确：

命令行输出显示uid指定的正确$username，而不是uid开始运行脚本的测试帐户的正确。

如果我通过 Apache 调用脚本，那么uid其余部分设置为apache用户的 id，并且永远不会更改。

我不相信我可以suExec在这里使用，因为在阅读了文档之后：

1. 我不能http://www.example.com/~username为每个$username. 脚本需要从一个位置运行，我需要uid在脚本中指定 from。

2. 我需要让脚本在运行时作为指定的用户名运行，而不是作为在 Apache 配置文件的虚拟主机指令中指定一次的单个用户名。每次新用户运行此脚本时更改此配置文件并重新启动 Apache 是不现实的。

使用时如何让 Perl 脚本作为 cgi-bin 运行以uid正确更改setuid()？

我们有两台机器（正在讨论中）运行 ClearCase——不同版本的 ClearCase。否则，它们在设置上几乎相同——相同的 Linux x86/64 内核等。

在一台机器上，视图中的 SUID 根程序作为 SUID 根程序工作。

在另一台机器上，视图中的 SUID 根程序不能以 SUID 权限运行，从而导致意外结果。

到目前为止，我们发现的唯一区别是：

• 工作视图：CC 7.0.1
• 非工作视图：CC 7.1.1.1

如果它重要，我可以给出完整的输出cleartool -version，但我怀疑它不会。这些是列出的第一个版本。

问题

1. 这是 ClearCase 版本之间的已知差异，还是配置项或其他？
2. 是否可以配置较新版本的 ClearCase (MVFS) 以允许 SUID 根程序“正确”运行？
3. 如果它是可配置的，我们如何更改配置使新版本允许SUID程序？

我们有无数台机器在许多不同的平台上运行 ClearCase。有传言说，在某些机器上，我们的 SUID 软件必须在“看不见”的情况下运行才能工作。现在有人报告了一个错误——花了一天的大部分时间来缩小差异。问题中解决的问题似乎是一个合理的解释。如果是别的东西，那就这样吧。我仍然需要我今天失去的头发再次回来！

额外的信息

所有视图都是动态的，而不是快照。

这是在cleartool lsview -l -full -pro -cview运行 ClearCase 7.0.1 的 SUID 程序工作的机器上的输出：

这是运行 ClearCase 7.1.1.1 的 SUID 程序不“工作”的机器上的输出：

检测到 SUID 程序不工作

问题不在于操作系统发出有关运行 SUID 程序的错误消息。问题是即使程序看起来是 setuid root，但在运行时，程序实际上并不是 setuid：

asroot这是未使用 SUID root 权限安装时的输出。在另一台机器上：

如果程序以 SUID root 权限安装，这或多或少是我期望的输出。

挂载信息

两个主要的 VOB 是 tristarp 和 tristarm。在 SUID 正常的机器上（手动包装以避免滚动条）：

在 SUID 不正确的机器上：

还有恶棍！（而且我以为我看过mount信息。显然。我看的不够准确，或者只在一台机器上 - 正在工作的机器 - 或其他东西。）奇怪的是，这两个 VOB 中只有一个安装了nosuid; 很奇怪。

我们有一个答案为什么！

谢谢，VonC。

探索

脚本中规定了使用文件来控制是否允许使用 SUID的脚本/etc/init.d/clearcase和/etc/clearcase程序；它存在于两台机器上，作为一个具有 root:root:000 权限的空文件。但可能还有其他一些重要的差异潜伏在这里——我已经向常驻的 ClearCase Guru 询问了这一点。但是，看起来差异更可能在于两台机器上的配置，而不是某些特定于版本的功能更改。两个版本表面上都支持该选项，尽管这两个版本都没有明显地调用该选项——除了 7.1.1.1 版本正在设法调用它，而 7.0.1 版本没有。/opt/rational/clearcase/var/adm/rational/clearcase/suid_mounts_allowednosuid

我有一个属于用户 'foo' 的 svn 存储库，可以通过 Apache 访问，我正在尝试从 post-commit 挂钩运行 svn update，该目录也属于 foo。

我创建了一个由 foo 拥有的 C 包装器并设置了 suid 位，如http://subversion.apache.org/faq.html#website-auto-update中所建议的那样，然后应该由 post-commit 脚本调用，运行由用户 www 数据。

尽管如此，当我从用户 www-data（使用空环境）运行包装器时，它实际上以用户 foo 的身份调用 svn update，但莫名其妙地我收到 svn 提示，询问用户 www-data 的密码。

包装器的代码，称为 svnupdater.c 与官方常见问题解答中建议的相同（当然具有正确的路径）。它由用户 foo 创建和编译。设置 suid 位后， ls -l inside /hooks 显示：

如果我然后 'su www-data' 并运行 'env - ./svnupdater' （来自 sh 或来自 bash）， ps aux 正确显示：

但我仍然可以看到 svn update 提示我：

当然，当提交后调用它时，整个事情都不会起作用。

我似乎无法真正理解问题出在哪里，因为这个策略是官方建议的，但看起来 svn update 绕过了 setuid 并且仍然使用实际用户......

我目前正试图弄清楚 SUID 位和相应的函数 seteuid 和 geteuid 是如何工作的。所以我写了这个小程序：

编译它，将其所有者更改为 root，并将文件所有者的 s 位更改为：

但随后产生的输出如下所示：

这是我不明白的。根据我的发现，第一次调用 geteuid 实际上应该返回该程序调用者的用户 ID（即 chris - 我的 ID 为 1000），但程序将 root 显示为有效用户 ID。谁能解释我为什么会这样？

nscd 服务在没有核心转储文件的情况下崩溃。

ulimit -c 是无限的。

有人说这是因为 nscd 在 /etc/nscd.conf 中设置了“server-user”时使用了“setuid”。

然后我在 /etc/nscd.conf 中的“server-user”行的开头添加了一个“#”来删除它，然后重新启动服务。

现在它以 root 身份运行，可以通过“ps -ef | grep nscd”检查。

但是，以下命令仍然无法使 nscd 生成核心转储文件：kill -ABRT nscd-pid 或 kill -s SIGSEGV nscd-pid

谁能告诉我为什么以及如何？提前致谢！

我有一个网络服务器，它会经常产生一个乳胶解释器（用 python 编写）。该解释器位于使用 jailkit 制作的 chroot 监狱中，因此必须以 root 身份启动。

我不希望服务器以 root 身份运行，也无法设置 bash 脚本。我可以编写一个调用脚本的 setuid c 程序，但我很确定这会导致很大的安全漏洞。

到目前为止，我想出的最好的方法是以 root 身份运行一个单独的网络服务器，其唯一的工作是生成解释器进程。

这样做的正确方法是什么？

我有一个以 www 用户身份运行的 Web 应用程序。然而，在某一时刻，它需要代表用户 Alice 和 Bob 从 Linux 文件系统中读取文件。

执行此操作的一种方法是启动 shell (Runtime.exec()) 并调用 C setuid 可执行文件来更改用户 ID 并读取文件。

有没有办法使用 JNI 来实现这一点（网络应用程序需要以 www 而不是 root 身份运行）？我尝试编写一个 Java JNI 程序，该程序在 Linux 上调用本机方法（我将这些本机方法设为 root 拥有并设置了 setuid 位）。但除非我以 root 身份运行 Java 程序，否则它不会让我切换用户 ID。有什么我想念的吗？有没有办法做到这一点？

谢谢！