TL;DR: I wrote a tool that allows to run a binary as a different owner/group.
You can download it from odedlaz/runas.
You must be thinking that I’m re-inventing the wheel. Well, I’m not. Let look at the following scenario:
- There’s a binary that you want to run in a non-interactive session.
- You want the binary to run with different permissions then the current user.
- You don’t want the user to be able to run any binary with any permissions,
only the one you want, with the requested user / group.
- You don’t want a child process to get created, because you want to run the binary
as part of a filter without any other processes getting in the way.
A good example would be to debug an elevated app, while running your editor regularly. for example -> running gdb and debugging a binary as root.
You probably don’t want to turn on Set owner User ID because that’s a major security hole.
You also can’t use
sudo as part of your editor / IDE because they execute the target process as child, which causes many issues.
sudo is also somewhat complex to configure, and honestly, I prefer to avoid using it alltogether.
A tool that is easy to configure & runs the target binary with requested owner:group.
runas is that tool. It does one thing, and (hopefully) does it well.
runas doesn’t have any complicated flags or knobs.
It just lets you run binaries:
But you need need the proper permissions to do so.
Notice I added
/usr/bin/bash which is linked to
runas follows links to their source, to make sure the right binary is called.
It also mimics the way shells parse commands so the configuration and command should be identical.
'whoami && id' is concatenated by the shell into one argument.
runas makes sure you don’t have to think about the way things get parsed.
Anyway, now the command works:
What if you want to allow the user to use any argument for a given binary?
The previous configuration only allows us to run
bash -c 'whoami && id.
You don’t need to think to much. The configuration is really easy:
And now any argument passed to bash will work, including the previous one:
You can also lock the user to run
bash -c commands exclusively.:
And now the user can run any argument that begins with
If we’d remove the previous command, we won’t be able to run bash without
runas is greedy. It’ll try to find a configuration that allows to run the given command, and will stop once it finds one.
What if you want to allow specific group members to run a command? Again, you don’t need to think to much:
And now any member of the
docker group can restart the docker daemon!
runas uses c++ 14, which comes with a built-in ECMAScript flavored regex library.
Using regular expressions can be really helpful when you want to have a lot of control over given permissions, which is still easy to understand..
A good example would be to allow the user to run only “readonly” operations on systemd units:
Now the user doesn’t need root permissions to perform
gosu is a tool that was invented to solve TTY & signaling issues, mainly for containers.
As I said before,
su run the target process as a child, which means all signals are passed to them, and sometimes aren’t forwarded propely.
gosu solves that issue, but doesn’t provide a permissions mechanism which makes it practically impossible to use on regular systems that need an extra layer security.
gosu is also written in Go, which is notoriously known for creating really big binaries:
- 1.23MB for the amd64 release
- 1.1MB for the i386 release