1

I'm writing an application using C on Linux. In my application, I need to do some tasks at the beginning with normal user (Non root user) while I need to do some tasks with root user in the middle of execution as well.

By the way, I cannot modify configurations of normal user. So I cannot add normal user to sudoers. I cannot modify any OS configurations as well.

What my application really do is execute applications, get their outputs for analysing.

Some applications need to be run with root. I use multi-threads to execute and analyse outputs of these applications in parallel then stores report of each application in a singleton called Report. I call these applications using execvp in sub-process.

The main purpose of my application is to automate software testing. And most task is required to run in software owner which shall not be root.

So, the problem is

  • how can I switch user during execution?
  • Is there anyway that I can implement this within 1 executable?
  • Do this with POSIX APIs is better.
  • Run my application with normal user, provide root password to my application, switch to root using root password.
Peter YANG
  • 11
  • 3
  • 1
    http://man7.org/linux/man-pages/man2/setuid.2.html – oakad Oct 17 '17 at 03:26
  • @oakad Thanks, but is that possible to launch my application with normal user, then switch to root using root password? – Peter YANG Oct 17 '17 at 04:35
  • 2
    No, although you can spawn a separate helper process that runs as root, and communicate with it via IPC. One way to do this is to set the setuid bit on the helper. Make the helper as minimal as possible, giving it only the very basic functions that actually need root access, and let your main app do the rest. – Charles Srstka Oct 17 '17 at 04:42
  • 1
    Either executable or an user who runs it must have an CAP_SETUID set. For users, the capabilities can be injected via `pam_cap` module in the auth chain. For executables, there's a `setcap` utility. – oakad Oct 17 '17 at 04:44
  • @PeterYANG: please **edit your question** to improve it and tell more about your application, motivation and context – Basile Starynkevitch Oct 17 '17 at 05:16
  • @BasileStarynkevitch Edited. – Peter YANG Oct 17 '17 at 05:38
  • Why a test environment should need root privileges? Why don't you use a virtual environment to allow user and root privileges without compromising system security? have you checked the `setgid(2)` and `setuid(2)` and related system calls? – Luis Colorado Oct 18 '17 at 05:47
  • @LuisColorado Because some parts of the software that we test needs root privileges. System security is not that important since all our users are engineers. We will guarantee that all commands that will be executed as root will be safe. As I know, `setuid()` cannot change from non-root user to root user. – Peter YANG Oct 18 '17 at 05:54
  • @PeterYANG, then you have better to test it in an environment without security concerns. – Luis Colorado Oct 18 '17 at 06:18

1 Answers1

4

Read more about setuid executables and setreuid(2) and execve(2) syscalls. Be careful, you'll need to put the setuid flag on the executable with chmod u+s (see chmod(1)) after changing its ownership (with chown(1)) and code carefully to avoid security holes.

(so I recommend to have your code reviewed by someone knowing the setuid mechanism and aware of security issues)

Setuid is the basic mechanism (used by su, sudo, super, login etc...) programs to get (or revoke) privileges. See credentials(7) & capabilities(7).

It could be safer to start some helper process (as root, or start some setuid executable perhaps in /usr/libexec/ ...) and communicate with it using some inter-process communication facilities (like pipe(7)...). For example, it is not recommended to use GUI toolkits like GTK or Qt in root processes. If your app has some GUI, it is reasonable to run its GUI in a non-root (ordinary user) process and run as root the (hopefully small) helper process doing the real job requiring special privileges.

Before coding, I recommend reading a good book like Advanced Linux Programming and syscalls(2) and the documentation of every system call you would use. Security aspects are especially important.

Setuid executables don't necessarily require or use any password; it is the other way round: programs requiring passwords (notably login, su, sudo etc....) are setuid (and they are free software on Linux so you can study their source code); try ls -l /bin/su /usr/bin/sudo /bin/login to check that.

Since you want to emulate various user environments, be aware of environ(7).

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547