My second idea is to run the controlpanel "remote" as it's own user (root?) which then creates separate users for each server and starts them as the appropriate user.
Esta não é a melhor solução, mas no interesse de você aprender, vou criticá-la de qualquer maneira. Vou chegar à melhor solução em apenas um segundo, mas isso é importante.
Repita depois de mim: nunca, nunca execute serviços voltados para a web como root se puder ajudá-lo (e neste caso você pode ajudá-lo, porque você tem controle sobre a aplicação).
A maneira correta de implementar isso é ter um daemon que inicia como root, mas descarta privilégios para um usuário não privilegiado. Você faria com que este daemon gerasse um segundo daemon antes de abandonar os privilégios, e o daemon sem privilégios falaria com o daemon privilegiado. O daemon privilegiado, então, executaria ações em nome do daemon sem privilégios.
Repita depois de mim: ter esse tipo de separação de privilégio é USELESS, a menos que o daemon privilegiado execute a validação. Isso significa que você não pode ter o daemon privilegiado aceitando cegamente comandos do daemon não privilegiado. Deve certificar-se de que o comando é algo que está certo e faz sentido. Se você não fizer a validação, você introduziu um . Ao escrever esse tipo de código de segurança, assuma que seu serviço voltado para a Web será comprometido. Eu ouço o que você está dizendo - "isso nunca vai acontecer". Sim, será. A segurança é toda sobre limitar o dano. Você também pode se beneficiar ao ler As seis ideias mais idiotas em segurança de computadores .
My third idea is to expand on the first one, and run all servers in some kind of sandbox where where the executables can't access files outside. But I do not technically know how this would be done or if it's even possible.
A +: essa é (parte de) a maneira correta de realizar esse tipo de segurança de aplicativo da web. A maneira de conseguir isso é gerando os processos do servidor em um chroot jail .