Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Next week, I will have a contractor install a web application on one of our servers. I created an account so that they can access our server through SSH.

The system is CentOS. Basically, beside basic user operations, they need to be able to:

  • install new librairies through yum
  • patch existing libraries
  • modify the apache configuration

I thus would like to give them sudo access, with some restrictions. For example, I do not want them to be able to modify the sudoers file, log as someone else, or to shutdown the server. Moreover, since I am liable for any misuse of this server in the organization I belong to, I would like to log every command that has been executed so that I can prove that I am not responsible if something goes wrong.

How should I proceed?

share|improve this question
From a security standpoint, I'm not sure you can give someone the ability to install software or patch libraries and not give them the keys to the whole castle. They could install malicious software, or patch glibc or similar, both of which would easily allow elevation of privileges without restriction. Both of these operations would need to be vetted by a trusted, competent user. – Darth Android Jul 18 '12 at 16:02
Yeah indeed, but I trust the contractor, it's just that I need to give guarantees to the network services of my organization (a big university). I guess we'll do the whole thing by screen sharing and type the super-user commands myself. What about the logging though? – Julien Bourdon Jul 18 '12 at 16:20
up vote 2 down vote accepted

You should not give them sudo access if you need to have accountability and can't easily hold them accountable. Maybe if you lock it down to specifically "sudo service apache2 reload" and let them run that one command with those arguments.

For editing configuration, use acl / filesystem permissions to give them access to write to the specific configuration files they should be changing. Giving them sudo access to an editor means they can edit/modify any file on the system, including sudo itself, or change sudo's configuration so that it doesn't log anything.

If they can install software, they can install malicious software. Don't let them do this, have someone you can hold accountable for the well-being of the system do it.

If they can patch libraries, they can patch core libraries and inject malicious code. Don't let them do this, have someone you can hold accountable for the well-being of the system do it (if it has to be done).

sudo itself can be configured to log every command to syslog, and you can set up syslog to forward log entries to a secured server over the network to keep accountability on the logs.

I would probably not give him sudo access, but configure the system such that he's in a group which can write to the apache configuration files and the webroot.

He'll need a way to tell apache to reload the configuration, so you might look into a ssh-key which isn't allowed to drop to shell, but triggers a service apache2 restart when someone logs in with it. Alternative would be to use a setuid program which takes no inputs and does the apache restart. Or he can just ping you via email or IM when he needs it reloaded.

For installing packages, I'd just have him send you a list and then after glancing over the list, install them. From a security standpoint, someone accountable (you) should be downloading / compiling / patching any libraries that need to be patched.

sudo should already be logging every command to syslog (at least, it does by default in Ubuntu if I remember correctly, might be different in your setup), so you should probably verify that it does regardless, and for added accountability, configure syslog to log to a remote syslog server which can be secured.

If you generally trust the contractor, then there's probably not a whole lot you really have to worry about. But if you have to be able to hold him accountable, then it's necessary to look at this from a "what's the worst he could do with priviledge X?" standpoint.

share|improve this answer
Very complete answer. Thank you very much. I already have the list of required libraries and I'm installing them as required. As far as the patch is concerned, it's just for a specific application (MapServer). I'll apply it myself after auditing it. I decided to not let them have a sudo access and just give them access to the virtual host configuration file they need, as well as a directory where they can install libs and their application. – Julien Bourdon Jul 18 '12 at 16:51
As far as the log is concerned, I'll just check the .bash_history. Yes, it can deleted but since they do not have root access anymore, it should be fine. Thanks for the service apache2 restart ssh access idea. I was not aware it was possible. – Julien Bourdon Jul 18 '12 at 16:54

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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