Giving people responsible for performance tuning access to user data is almost inevitable if you run anything remotely like unix. After all, it may require twea

Giving people responsible for performance tuning access to user data is almost inevitable if you run anything remotely like unix. After all, it may require tweaking kernel parameters, changing init sctripts or reinstalling applications compiled with different optimizer settings. All of these operations require root, which is an all or nothing affair in unix. (You can do some tricks with /etc/sudoers to restrict what else people who need root for a specific task can do as root, but writing a sudoers file that allows serious performance tuning and is still airtight might prove a challenge.) This has in fact been criticized as a major design flaw of the unix authorization model. To prevent problems like these you need a more fine grained authorization model that separates access to the system and its configuration from access to the data, so that even if I can replace an application with something else, I still cannot make it write data to a location of my choice. This would reduce the number of people who I need to absolutely trust from everybody who may need to change some minor configuration file to the handful of people managing the security kernel of the OS. Systems like that are possible, but not easy to implement and mange correctly and sometimes inconvenient to use, so peole go the easy way and assume that everyone that is a member of a group mentioned in /etc/sudoers is trustworthy or at least lack the criminal energy to bypass the restrictions sudo can enforce. Most of the time, this works.