Linux 中仅更改一个线程的 UID/GID
有没有一种方法可以仅更改多线程进程中一个线程的UID/GID？
否则不会强制执行 ACL 和配额，不会使用正确的 uid/gid 创建新文件/目录等。
这样做的原因是编写文件服务应用程序 - 除非调用者的 uid/gid 设置为正确的用户， 应用程序通常可以在开始时自行 fork() 并在单独的进程中处理每个用户请求。 如果需要共享数据，就必须经过某种共享内存。 然而，例如，FUSE（linux 用户文件系统）默认使用多线程，并且与 python 绑定结合使用，尝试使用分叉模型是不切实际的。
整个进程的“一致”UID 似乎符合 POSIX 标准，但是旧的 Linux 不遵循 POSIX，并允许不同线程使用不同的 uid。 新内核似乎遵循 POSIX，是否有某种方法允许旧的“损坏”行为？
Is there a way to change UID/GID only of one thread in a multithreaded process?
The reason for this is writing a file-serving application - the ACL's and quota are not enforced unless the uid/gid of the caller is set to the correct user, new files/directories are not created with correct uid/gid etc.
The network applications can usually fork() themselves at the beginning and process each user request in separate process. If there is a need for shared data, it must go through some kind of shared memory. However, e.g. the FUSE (linux user filesystem) by default uses multithreading and in conjuction with python bindings it wouldn't be practical to try to use a forking model.
The 'consistent' UID for a whole process seems to be according to the POSIX standard, however old Linuxes didn't follow the POSIX and allowed different uids for different threads. The new kernels seem to follow POSIX, is there some way to allow the old 'broken' behaviour?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
要仅更改一个线程的 uid，您需要直接使用系统调用： syscall(SYS_setresuid, ...); libc 函数 setresuid() 将为所有线程同步它（使用它发送到所有线程的信号）！
To change the uid only for one thread you need to use the syscall directly: syscall(SYS_setresuid, ...); The libc function setresuid() will synchronize it for all threads (using a singal which it sends to all threads)!
Linux 特定的
setfsuid()/setfsgid()是按线程而不是按进程。 它们是专门针对此用例（文件服务器）而设计的。请注意，
access()仍将使用真实的 uid 和 gid 检查访问权限 - 这是设计使然（它的目的是回答问题“运行此二进制文件的用户是否应该具有给定的访问权限”）到此文件”）。 对于setfsuid()/setfsgid()情况，您应该尝试请求的操作并检测由于此时缺乏权限而导致的失败。The Linux-specific
setfsuid()/setfsgid()are per-thread rather than per-process. They're designed specifically for this use case (file server).Note that
access()will still check access using the real uid and gid - that is by design (it is intended to answer the question "should the user who ran this binary have the given access to this file"). For thesetfsuid()/setfsgid()case you should just try the requested operation and detect failure due to lack of permission at that point.