Programmatically requesting elevated rights in Linux

1.1k views Asked by At

(This question has identical title, but question body asks it in scripting point of view, e.g. su -c, don't dupe this to that)

I have a Qt GUI app that needs to perform some file operations in /etc based on user input. One option would probably to use system() with sudo, but even that requires messing with sudoers file in some point. I also would like not to do system() plus script hacks to modify the files, but proper file operations.

What is the best way to programmatically elevate my applications rights to do this?

Edit: as a bonus, it'd be nice if it would work on Maemo/Meego/other handhelds too (afaik PolicyKit isn't available there..)

3

There are 3 answers

0
lorenzog On BEST ANSWER

I would write a separate program altogether. Something along the lines of this philosophy. Basically - write a simple program that does exactly what you need, and control its behaviour with file permissions on the filesystem. Mainly,

Do as little as possible in setuid programs.

A setuid program must operate in a very dangerous environment: a user is under complete control of its fds, args, environ, cwd, tty, rlimits, timers, signals, and more. Even worse, the list of controlled items varies from one vendor's UNIX to the next, so it is very difficult to write portable code that cleans up everything.

Of the twenty most recent sendmail security holes, eleven worked only because the entire sendmail system is setuid.

Only one qmail program is setuid: qmail-queue. Its only purpose is to add a new mail message to the outgoing queue.

And,

Do as little as possible as root.

The entire sendmail system runs as root, so there's no way that its mistakes can be caught by the operating system's built-in protections. In contrast, only two qmail programs, qmail-start and qmail-lspawn, run as root.

1
Delan Azabani On

You could use PolicyKit, which is gradually superseding gksu/su/sudo, especially on Ubuntu, for its higher security and fine-grained control because of elevating actions, not the whole program.

0
gpeche On

Create a helper setuid program that does only the things you want to do, and fork / exec your application from it. Then drop privileges in the child process. Both applications could communicate over pipes, sockets, or something like that.

Have in mind that setuid programs are a security risk and so you should be very careful when implementing one.