Is using a wrapper to execute a script a good practice ?

In such case can the following set of wrapper / script be considered as safe:


#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <unistd.h>
#include <sys/types.h>

int main(void)
    if (setuid(geteuid()) != 0)
        fputs(strerror(errno), stderr);
        return EXIT_FAILURE;
    system("cat script | /bin/bash");
    return EXIT_SUCCESS;


/bin/echo -n "[Whoami]: "

/bin/echo -n "[ls /root]: "
/bin/ls /root

The script file does not contain any shebang. Would it change anything if I'd have added one ?

In the Wrapper, could I have simply called the script as I'd execute any Linux script instead of cat'ing its content into a shell ?


Given that it provides a gateway to privileged access, using setuid programs should be considered a last resort for providing functionality. This is usually exploited by invoking a further program from the setuid one - something your code does by design. Since there are no unusual permissions on script (it doesn't even need to be executable) there is a lack of transparency in what the code does. Not using an explicit path is a rookie mistake - your code can be compromised simply by changing $PATH

Given that there is a well defined way to provision such privileged access on unix systems, which has been well tested, is widely understood and provides for flexible and granular access control (I'm talking about sudo in case you hadn't guessed) why would anyone want to implement the code above?

  • Effectively you're right in the way that I definitely wasn't using what was meant for what I wanted to do. I'll use the sudo command / configuration from now on. Now, just out of curiosity, would the script be considered secure with the additional changes given in the edited version ? – Ra'Jiska Oct 8 '17 at 18:56
  • better - although still no path on 'script' means I can get around your security by just changing directory. :) – symcbean Oct 9 '17 at 11:00

No this is not considered safe, you do not make any attempt to sanitize the environment you are running in. Which will let the attacker manipulate what gets executed as root by manipulating the environment through various environment variables, from PATH to LD_PRELOAD. Specific vulnerabilities vary, and there is some effort to mitigate in dynamic loader but still you should sanitize environment and ensure you are in control of what gets executed in privilege context ensure only the relevant input is passed and nothing else ensure relevant input is valid.

  • Alright for path, effectively I did not realise the PATH variable was carried over after a SUID. I also reset the IFS variable from the script and as far as I know it also holds a security issue if the user is able to have access to it. Furthermore regarding the LD_PRELOAD, this post: stackoverflow.com/questions/426230/… ; says it may not be used with SUID. – Ra'Jiska Oct 8 '17 at 18:49
  • Don't try finding and plugging all the holes yourselves. sudo did it better (and even sudo has had security issues in the past). – Meir Maor Oct 8 '17 at 20:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.