Questions tagged «setuid»

8
在shell脚本上允许setuid
该setuid权限位告诉Linux与业主,而不是执行者的有效用户ID运行程序: > cat setuid-test.c #include <stdio.h> #include <unistd.h> int main(int argc, char** argv) { printf("%d", geteuid()); return 0; } > gcc -o setuid-test setuid-test.c > ./setuid-test 1000 > sudo chown nobody ./setuid-test; sudo chmod +s ./setuid-test > ./setuid-test 65534 但是,这仅适用于可执行文件。Shell脚本忽略setuid位: > cat setuid-test2 #!/bin/bash id -u > ./setuid-test2 1000 > …

2
正确使用setuid位
我有一个由普通用户运行时需要root特权的进程。显然,我可以使用“ setuid位”来完成此操作。在POSIX系统上执行此操作的正确方法是什么? 另外,如何使用使用解释器的脚本(bash,perl,python,php等)来做到这一点?
45 scripting  setuid 

6
用root权限以编程方式写入文件的最安全方法是什么?
大型应用程序需要在特定时间对需要根权限的文件执行少量写入操作。它实际上不是文件,而是硬件接口,它作为文件公开给Linux。 为了避免给整个应用程序以root特权,我编写了一个bash脚本来执行关键任务。例如,以下脚本将启用硬件接口的端口17作为输出: echo "17" > /sys/class/gpio/export echo "out" > /sys/class/gpio/gpio17/direction 但是,由于suid我的系统上的bash脚本已禁用,我想知道什么是实现此目的的最佳方法。 使用此处介绍的一些解决方法 sudo从主应用程序使用调用脚本,并相应地编辑sudoers列表,以避免在调用脚本时要求输入密码。给sudo特权我有点不自在echo。 只需使用编写一个C程序,fprintf并将其设置为suid root。硬编码字符串和文件名,并确保只有root可以编辑它。或从文本文件中读取字符串,类似地确保没有人可以编辑该文件。 我没有想到的其他解决方案比上面介绍的解决方案更安全或更简单?

1
解决此glibc问题的最佳方法是什么?
我管理一个Gentoo Hardened框,该框使用文件功能来消除对setuid-root二进制文件(例如/bin/ping具有CAP_NET_RAW等)的大多数需要。 实际上,我剩下的唯一二进制文件是: abraxas ~ # find / -xdev -type f -perm -u=s /usr/lib64/misc/glibc/pt_chown abraxas ~ # 如果我删除setuid位或重新挂载我的根文件系统nosuid,则sshd和GNU Screen停止工作,因为它们调用grantpt(3)了它们的主伪终端,并且glibc显然执行了该程序来对下的伪伪终端进行chown和chmod /dev/pts/,而GNU Screen会在何时关注此函数失败。 问题是,联机帮助页上grantpt(3)明确指出,在Linux下,devpts安装了文件系统后,不需要此类帮助程序二进制文件;内核会自动将从站的UID和GID设置为打开的进程的实际UID和GID /dev/ptmx(通过调用getpt(3))。 我编写了一个小示例程序来演示这一点: #include <string.h> #include <sys/types.h> #include <sys/stat.h> #include <stdlib.h> #include <stdio.h> #include <unistd.h> int main(void) { int master; char slave[16]; struct stat slavestat; if ((master = getpt()) …

1
所有者/根和RUID / EUID之间的区别
我对问题中提到的概念还比较陌生,从不同的来源阅读它们只会使它们更加混乱。所以这是我到目前为止所了解的: 当我们获得文件权限时,它们如下所示: -rwsr-xr-- 1 user1 users 190 Oct 12 14:23 file.bin 我们假设用户user2谁是该组中users试图执行file.bin。如果未设置setuid位,则意味着的RUID和EUID file.bin等于的UID user2。但是,由于设置了setuid位,这意味着RUID现在等于的UID user2,而EUID是文件所有者的UID user1。 我的问题是: 文件的所有者和之间有什么区别root?是否root具有与所有者相同的权限?还是在权限列表中需要一个单独的条目root? RUID和EUID之间的区别? 据我了解,RUID和EUID仅适用于进程。如果是这样,为什么它们具有用户ID的值? 如果RUID是创建流程的用户,而EUID是当前正在运行流程的用户,则此问题中第一个答案的第一句话对我来说没有任何意义。 我是否正确理解setuid位的作用?

2
gdb可以调试suid根程序吗?
我编写了一个调用setuid(0)和的程序execve("/bin/bash",NULL,NULL)。 然后我做了 chown root:root a.out && chmod +s a.out 当我执行时,./a.out我得到一个root shell。但是,当我执行gdb a.out此操作时,它将以普通用户身份启动该过程,并启动一个用户外壳程序。 所以...我可以调试setuid根程序吗?
16 debugging  setuid  gdb 

2
Setuid位似乎对bash无效
我进行了一些实验,发现有些奇怪:将setuid位设置在位于bash的bash副本上/usr/bin/bash-test似乎没有任何效果。当我运行的实例时bash-test,未将主目录设置为/root,当whoami从中运行命令时bash-test,未将用户名报告为root,表明该用户名bash-test未以root身份运行。但是,如果我将setuid位设置为on whoami,则按预期,我在任何shell中都是root用户。 我也尝试设置setuid位,/usr/bin/bash并观察到相同的行为。 在bash上设置setuid位时,为什么bash不能以root身份运行?selinux可能与此有关吗?
14 linux  bash  setuid 

3
GID是什么意思?
GID实际上是什么意思? 我已经用Google搜索了,这就是linux.about.com所说的: 进程的组标识号。有效的组号在/etc/group和/etc/passwd文件的GID字段中给出。启动进程时,其GID设置为其父进程的GID。 但是,这是什么意思? 我对文件夹的权限当前位于 0755 我了解如果我为所有者设置了UID,它将是 4755 如果我设置组的GID,它将是 2755 如果我为其他人设置粘滞位 1755 设置这些权限甚至重要吗?

5
如何在shell脚本中放弃root特权?
OpenVPN中的“ --up”选项通常用于路由等。因此,在OpenVPN放弃root特权以无人运行的情况下进行处理。但是,我正在调用需要以非特权用户身份运行的shell脚本。 我怎么做?我研究了Drop Process Privileges,特别是多项式和tylerl的答案,但是我不知道如何实现。我在Centos 6.5中工作,并且suid被阻止为“ chmod u + s”和“ setuid()”。 有一个OpenVPN插件(“ openvpn-down-root.so”),该插件使“ --down”选项调用的脚本能够以root用户身份运行。可能存在等效项,例如“ openvpn-up-user.so”,但我没有找到它。 编辑0 根据Nikola Kotur的回答,我已经安装了Ian Meyer的runit-rpm。尽管chpst命令在终端中有效,但在up脚本中,它失败并显示“找不到命令”。起作用的是“ sudo chpst”以及设置适当的显示和语言。请参阅为什么我的终端无法正确输出unicode字符?鉴于此,up脚本需要以下四行: LANG="en_US.UTF-8"; export LANG GDM_LANG="en_US.UTF-8"; export GDM_LANG DISPLAY=:0; export DISPLAY sudo chpst -u user -U user /home/user/unprivileged.sh & 编辑1 根据0xC0000022L的评论,我发现“ sudo -u用户”和“ sudo chpst -u用户-U用户”一样有效: LANG="en_US.UTF-8"; export LANG GDM_LANG="en_US.UTF-8"; export …

1
root拥有setuid位的程序
Ping是根用户拥有的,设置了用户ID位的程序。 $ ls -l `which ping` -rwsr-xr-x 1 root root 35752 Nov 4 2011 /bin/ping 据我了解,如果用户运行ping进程,则有效用户ID将从实际用户ID(即启动进程的人的用户ID)更改为用户ID根。但是,当我尝试此操作并查看ps的输出以查看ping进程是否以root用户身份运行时,仍然显示了真实的用户ID。 ps -e -o user,ruser,euser,cmd,args | grep ping sashan sashan sashan ping -i 10 -c 1000 www.goog ping -i 10 -c 1000 www.google.com

4
真实有效的用户ID如何工作?
当普通用户想要更改passwd文件时,setuid将为该用户提供有效的用户访问权限。用户暂时成为root用户,可以编辑passwd。 但是,您只能正确编辑密码,而不能所有人吗?但是,您的有效用户访问权限是root。那么,为什么不允许您更改除您之外的其他密码? 当使用setuid运行程序时,当有效用户为root时,实际用户身份仍然是您的名字,这实际上意味着什么?
13 setuid 


2
组成员身份和setuid / setgid流程
其流程去缓和权限通过setuid()和setgid()似乎没有继承的UID / GID他们设置了组成员。 我有一个服务器进程,必须以root用户身份执行才能打开特权端口。后,它的去升级到一个特定的非privilleged UID / GID,1 -例如,其的用户foo(UID 73)。用户foo是组的成员bar: > cat /etc/group | grep bar bar:x:54:foo 因此,如果我以登录foo,则可以读取/test.txt具有以下特征的文件: > ls -l /test.txt -rw-r----- 1 root bar 10 Mar 8 16:22 /test.txt 但是,std=gnu99当以root 身份运行时,以下C程序(compile ): #include <stdio.h> #include <fcntl.h> #include <unistd.h> int main (void) { setgid(73); setuid(73); int fd = open("/test.txt", O_RDONLY); …

4
sudo`要求哪个用户密码?
$ ls -l /usr/bin/sudo -rwsr-xr-x 1 root root 136808 Jul 4 2017 /usr/bin/sudo 因此sudo,任何用户都可以运行该用户,并且运行的任何用户都sudo将以root作为该进程的有效用户ID,因为已设置了set-user-id位/usr/bin/sudo。 从https://unix.stackexchange.com/a/11287/674 sudo和su之间最明显的区别是sudo需要用户密码,而su需要root用户密码。 要求哪个用户密码sudo?它是由进程的真实用户ID表示的用户吗? 如果是,是否没有任何用户可以通过运行sudo然后提供自己的密码来获得超级用户特权?Linux可以限制某些用户吗? 它是纠正sudo输入密码请求后 execve()开始执行main()的/usr/bin/sudo? 由于进程的euid已更改为root(因为/ usr / bin / sudo的set-user-id位已设置),以后sudo要求输入密码的目的是什么? 谢谢。 我已阅读https://unix.stackexchange.com/a/80350/674,但未回答上述问题。

2
为什么setuid在可执行文件上不起作用?
我知道在脚本上启用setuid会带来安全问题,因此默认情况下处于禁用状态,但是希望它对可执行文件有效。我创建了一个可执行文件,该文件按照本文中所述的说明将uid显示为输出:在shell脚本上允许setuid 但是它在运行之前和之后都返回相同的uid(1000)sudo chmod +s ./setuid-test。我认为这意味着setuid对我的可执行文件没有任何影响,为什么以及如何解决? 源代码: #include <stdio.h> #include <unistd.h> int main(int argc, char** argv) { printf("%d", geteuid()); return 0; } 构建并运行 $ gcc -o setuid-test setuid-test.c $ ./setuid-test 1000 $ sudo chown nobody ./setuid-test; sudo chmod +s ./setuid-test $ ./setuid-test 1000 运行时ls -la,这是我得到的: me@me:~$ ls -la setuid-test -rwsrwsr-x 1 …

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.