How to start (or find) a process with RUID different from EUID

processpssetuid

Inspired by one of the previously answered questions, I tried executing a program by a user who was not its owner — and the process's RUID and EUID remained the same. (Unless I read the answer wrong and that's not how you can achieve the difference.)

Then I tried opening a program as another user via sudo — and still nothing.

I've scanned through all already-existing processes (I think) via ps axo euid,ruid,comm -e g, and none of them had different RUIDs and EUIDs.

How can I achieve (or find the processes with) the difference? Some specific commands would help, because I could have possibly made some mistakes in some steps.

Best Answer

Invoking an executable that you don't own is nothing remarkable. Most executables on the system belong to root, and running them does not give the user any extra privileges.

It's only setuid executables that start with the effective UID set to the owner of the executable while the real UID remains the real UID of the invoking process.

sudo is setuid root, so it runs with the effective UID 0 and your real UID. But when it invokes another command, it sets both the effective UID and the real UID to the target user. You'd have to catch sudo itself in order to observe an EUID that differs from the RUID. This will be too quick to see unless sudo prompts you for a password.

You can easily observe the differing UIDs by running the passwd command as a non-root user. While the prompt is being displayed, run ps in another temrinal:

ps -o user,ruser -C passwd

To find all running processes with differing EUID and RUID, you can use

ps -e -o user= -o ruser= | awk '$1 != $2'

It's normal not to find any, most setuid processes are short-lived.

Related Solutions

Using SUID bit to drop privileges

As you correctly state a SUID bit, sets the effective user-id of the new process to the owner of the program file being run. There's no concept of raising or lowering privileges. Often the user to which one "suids" is root, but it can just as legitimately be any other, and doesn't really change the concept of SUID, when you choose another, apart from some users have access to certain resources. However the root user is a little bit special, and the man page for setuid, explains the subtle differences. I don't think there is a special name for changing to a non-root user, and I have never associated suid meaning going up in privilege, just changing user.
Since you are developing the master yourself which runs as root it can setuid to any user after forking but before exec-ing the new process, I dont see that suid bit has to be used on executable at all, and incidently if you don't, then if any-old user ran the player, since executable is not suid, they wouldn't be able to run it correctly since setuid will fail if they were not root. For me this seems like better security, than using suid bits on executable files.

--- edit 1

So your manager (running as real and effective uid=0) starts player and you code/control player (not manager). If you do nothing special, then player will run with real+effective uid=0 and you want to prevent this.

You could just switch uid in player, no SUID bits on player, no need.

Determine the owner of the session of a process

Maybe I am over simplifying, but, can you just do this?

ps -p <pid> -F tty

Here is an example:

$ ps -p 6947010
      PID    TTY  TIME CMD
  6947010  pts/0  0:00 ksh

$ ps -p 6947010 -F tty=
 pts/0

Here is how you could determine to allow or deny access to a particular process:

You first determine who owns the process and which pts device started it by using:

$ ps -p <PID> -F tty=,user=
 pts/X  <username>

Then you check the owner of the pts/X device, like this:

$ ls -l /dev/pts/X
crw--w--w-    1 <username>  <group>     21,  0 Apr 18 13:27 /dev/pts/0

If the owner of /dev/pts/X is the same as the process owner then then the process was started by the login user and you will grant access, if the owner of the /dev/pts/X device is not the same as the owner of the process then you deny access.

Best Answer

Related Solutions

Using SUID bit to drop privileges

Determine the owner of the session of a process

Related Question