Hm. Looks like it lets users temporarily assume privileges of the user or group that owns an executable.
A common example I’m seeing is passwd, which has a permission set of -rwsr-xr-x root root.
The position of the s means that “suid” is set, which means that if I run it as user casey, it actually gets run as root. I guess? Or it gets run as me but with root privileges? I wonder who the process owner is. I’m gonna experiment.
I made a root-owned a+x u+s script that ran ps aux | grep $$ and ran it as my regular user and it said my regular user is the process owner and I have to say, I did not learn anything from that.
Maybe if I make it touch a root-owned a-w file, then if that file’s last-modified date changes even though I ran it as my regular user…?
Permission denied. Nope, it turns out I still don’t understand suid.
I ran into just this problem literally yesterday 😅. It turns out that many Linux distros (not sure which ones exactly but I’m on fedora and it does this) will ignore the suid bit on shell scripts because apparently they’re too easy to exploit for privilege escalation. Sure enough I tried it again with a c program instead of a shell script and the suid bit worked; I was able to write to a file I didn’t have permission for normally. I’m not totally sure exactly which kinds of executables are allowed and which aren’t; it might be binaries only.
Hm. Looks like it lets users temporarily assume privileges of the user or group that owns an executable.
A common example I’m seeing is passwd, which has a permission set of -rwsr-xr-x root root.
The position of the s means that “suid” is set, which means that if I run it as user casey, it actually gets run as root. I guess? Or it gets run as me but with root privileges? I wonder who the process owner is. I’m gonna experiment.
I made a root-owned a+x u+s script that ran
ps aux | grep $$and ran it as my regular user and it said my regular user is the process owner and I have to say, I did not learn anything from that.Maybe if I make it touch a root-owned a-w file, then if that file’s last-modified date changes even though I ran it as my regular user…?
Permission denied. Nope, it turns out I still don’t understand suid.
I ran into just this problem literally yesterday 😅. It turns out that many Linux distros (not sure which ones exactly but I’m on fedora and it does this) will ignore the suid bit on shell scripts because apparently they’re too easy to exploit for privilege escalation. Sure enough I tried it again with a c program instead of a shell script and the suid bit worked; I was able to write to a file I didn’t have permission for normally. I’m not totally sure exactly which kinds of executables are allowed and which aren’t; it might be binaries only.
Huh!
Thanks, that would have had me confused for a good while.
Same behavior on Debian.