地球/地球奇形怪状

Question

我有一个简单的代码，基本上如下：

package main

import (
    "fmt"
    "golang.org/x/sys/unix"
)

func main() {
    fmt.Printf("real: %d, effective: %d\n", unix.Getuid(), unix.Geteuid())
}

它基本上输出真实有效的用户id。现在，使用：go build main.go构建一次；我还调用sudo chown root:root main && sudo chmod 4755 main来获得文件的-rwsr-xr-x权限。

如果我理解setuid位( s部分)的概念，它允许我稍后在源文件中使用setuid (请注意，我必须与runtime.LockOSThread一起使用unix.Setreuid或unix.RawSyscall )。然而，无论总是返回什么，当前编译的代码都是real: 1000, effective: 1000。

一开始，我想可能是一些Go代码的情况，双重和三重检查它，然而，结果仍然是一样的。然后，我走得更远，在c中作了一个模拟：

int main(int argc, char* argv){
   printf("real: %d, effective: %d\n", getuid(), geteuid());
   fflush(stdout);
}

编译，chown‘’ed到root:root，chmod‘’ed到4755，然后你猜怎么着？它仍然做同样的事情，它输出real: 1000, effective: 1000。

因此，如果这两个版本: Go和C版本一旦编译，在权限方面都进行了适当的更改，则返回相同的结果:忽略设置，否则可能会对系统设置做一些事情。

Update我发现这种情况可能是由挂载驱动器的nosuid选项造成的；所以我已经将可执行文件复制到另一个驱动器，后者没有这样的选项。还是没有效果。

那么，我该怎么做呢：

1. 来对抗这种行为？
2. 去探测未来的这样一个环境？

期待着看到你的建议。

Answer 1

对nosuid选项的深入研究表明，包括编译在内的整个过程必须发生在没有 nosuid选项的驱动安装的上。

所以，基本上来说，解决这个问题的步骤是：

1. 在禁用nosuid驱动器上创建一个目录；
2. 确保目录组是您的组；
3. 确保目录组权限具有w选项；
4. 将源文件复制到此目录；
5. 目录中的go build；
6. 应用chown root:root对结果进行分析；
7. 应用chmod 4755对结果进行分析；
8. 享受来自/nonosuid/目录/的结果

要检测环境，您需要在安装过程中搜索没有nosuid参数的目标。