InfoSec - Applicable knowledge

I’m always learning something new. Over the last couple days, I learned:

• How setuid can be used to change the run as user for a running process
• Why changing permissions on a file isn’t immediately reflected in a running process

What is so neat about this week’s lectures is that the material directly transfers to my job as a software engineer; literally, the very next day (or maybe the same day), I leveraged my knowledge of setuid. At work, we wrote and deployed administrative command line tool that needs to be executed as root. And while logged into our system, we ran the tool, and it had an unintended side effect of overwriting some files owned by another user. As a result, when the main application ran as its normal user, it bombed out due to lack of read permissions. So, we added some code so that if the process is launched by root – by checking if its userid is equal to 0 – we then call setuid and setguid.

Separately, I learned that when you make an open system call, which returns a file descriptor, the operating system itself will index into (per process) open file table, checking the inode metadata and verify that the running user has permissions to access the resource. Note: this doesn’t happen with read or write system calls. That means, if you have a valid file handle and while reading, the file’s permissions change, you can still continue reading until the process stops.