Log sudoer & email reporting

This is not a good idea. There are several weaknesses in this plan.

1. If you don't trust him, don't give him access. E-Mailing you his evilness at the end of the day won't help anything if he has done it already by evening. And if he really wanted to compromise the system he'd surely find a way to manipulate those pesky emails. It's a pretty easy calculation, if a user you don't trust has administrative privileges on the system you can't trust the systems observation.

2. If he really needs access, can we work around superuser privileges ? And if he really needs sudo, can it be restricted to just some commands.

The simple way to do this is to set up logwatch on your machine. By default logwatch generates an email every night that includes various system details and important log messages. By default it includes all logged sudo commands too.

Then just set the logwatch email address in /etc/logwatch.conf to your address, and you will receive those mails every night.

I strongly advise you to talk to the user in question and share your concerns with him honestly. Much better for him to know that he can ask you if he is confused about anything than for you to find mistakes in the logs. Trust, but verify.

This is the classic example of the concept, Principle of Least Privilege. That is, the user should have the least access necessary to perform their job functions. The real solution to your problem is to implement a standard operating procedure that limits full admin rights to a server to only those people who actually administer the server. While that is easy to suggest, it will take a fair amount of work on your part to implement, and will typically require a change in business process for the DBAs, application admins, etc.

What you need to do is have a sit down with the user and determine exactly what the user does using this system, and map out what access rights that would entail. The really tricky thing here is determining what they need to do as opposed to how they do it. Some of the types of questions you should start with are things like do they need to edit system files, restart services, view log files, etc.

Once you have that information cataloged you can start to figure out if there is anything you should be doing instead. For instance, if a file in /etc/sysconfig need to be changed, should the the user prep the change and then give it to a sysadmin to deploy? Or if they need to be able to manage services, what commands are actually required to do that, and does it have to be done as root or as a service account?

At the end of the exercise you should have a list of commands they need to execute (and as whom), files they'll need to access, and procedures that you and the user can follow for making abnormal changes.