A Cool Guide for Linux File Permissions

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.

8 comments

I always just chmod 777 and I'm done. 😂
- Are you my coworker?
- "I'll just chmod 777 -R * real quick to test...."
  Three years later in production...
Could you explain s and t a little more?
- i am just reposting. wait till someone knowledgeable that could chip in on the subject
  
  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.