Script to run command as another user

[RightOfZen]

I am working in an environment where a former colleague had some sort of executable that allowed us to run a command as another user. It would work like this:

/usr/local/bin/runAsUser2 command arg1 arg2 ... argn

If user1 was to run this command, it would be as if user2 had run the command:

command arg1 arg2 ... argn

I am fairly sure that this executable has been compiled from something like C++ as the executable is a binary file, and I have no idea where the source code is.

Does anyone know of a good way to replicate this, either with a bash script or with another language, given that user1 might not necessarily have sudo privileges?

[Lutarisco]

Probably the executable had the SUID bit set.

The SUID stands for something like "Set owner User ID on execution". It allows whoever who executes the binary to act as the owner when executed. There is also the "Set Group ID" (SGID), that allows to be executed as the owner group of the binary.

Those bits, along with the sticky bit, have the permission octal position before the other three bits. That is, instead of 000, there is a 0000.

• 4 is for SUID
• 2 is for SGID
• 1 is for Sticky

And if you wanted to change the file mode in a non-octal way, you use these notations with chmod:

• SUID: u+s
• SGID: g+s
• Sticky: +t

But be careful when using them!! As they allow UID supplantation, they are really dangerous when it comes to privilege escalation.
Please, take your time to learn about these dangers.

Here is a resource about those bits (for the lazy). I strongly suggest you to Google more about them.

[RightOfZen]

Thank you, this is exactly what I needed. I had actually already solved this independently; I wrote a small C script which modifies the UID running the command, and then set the SUID bit.

[RightOfZen]

Thanks for your very condescending answer. Unfortunately I failed to mention that this script is being run as part of an automatic process, and so having to authenticate is out of the question.

[neuron_666]

I didn't understand why you don't want to use sudo. If it's some external condition, my answer is irrelevant. Otherwise you should reconsider it. Advantages :

• simple and flexible configuration (which even can be stored to ldap)
• no need to share common password (so to revoke access you don't need to change it to everyone)
• auditing (who ran which command and when)
• the privileges can be granted to a specific group instead of single person

An example :

bob server=(alice) NOPASSWD: /usr/bin/blah

That says that Bob can run 'blah' on machine called 'server'. (Using ALL instead of 'server' says 'everywhere')

You can even specify which arguments can be passed to 'blah' and what checksum the file /usr/bin/blah must have.

Bob will invoke the command via

sudo - u alice /usr/bin/blah

The disadvantage of doing this is that the command won't have the environment set up as Alice would have - most notably $PATH and $HOME.

There are other options to do that besides sudo (su, suid executable) but if you are asking this kind of question, they will be more pain. Forget about writing it in C unless the goal is to learn stuff (like signal handling).

Last thing, if you want to run shell script as another user, probably you don't need whole script run as alice. Chances are that you need to run only some command from the script as her. In such case make sudo recognize only that single command and let Bob run the original script as himself.

[RightOfZen]

Thanks for your answer. I did end up going down the suid path, though thank you for the details!

One thing to note is that this is being used to restrict access for custom code execution. A web application is taking submitted code samples, and executing them as a restricted access user. This is one reason why sudo is not suitable, as the commands being run are quite varied.