Vous allez peut-être dans le mauvais sens. Au lieu de donner à un utilisateur un shell bash "restreint", vous ne devez lui donner accès qu'aux commandes dont il aurait besoin pour s'exécuter en tant que root. Par exemple, dans votre fichier sudoers :
tomc ALL=(root) /usr/bin/vim /etc/myapp.conf
tomc ALL=(root) /usr/bin/less /var/log/myapp/*.log
Soyez prudent lorsque vous autorisez les utilisateurs à exécuter vim en tant que root. Vim a de nombreuses fonctionnalités intégrées, comme les échappements vers le shell et la possibilité d'exécuter des commandes depuis vim. Selon votre distribution, vous pourriez avoir sudoedit disponible. Cela fonctionne de la même manière qu'un Vim normal, sauf qu'il est conçu pour gérer les échappements du shell et autres.
Sur mon Synology Diskstation exécutant DSM 6, seuls les utilisateurs administrateurs peuvent ssh de manière cohérente (les utilisateurs non administrateurs ont un shell comme /sbin/nologin dans /etc/passwd - vous pouvez le définir sur /bin/sh pour autoriser temporairement ssh, mais au redémarrage le fichier /etc/passwd est réinitialisé). Pour cette raison, une sorte de restriction sudo est nécessaire pour un compte qui n'existe autrement que pour exécuter, par ex. /sbin/poweroff. Les lignes suivantes dans /etc/sudoers ont fonctionné pour moi :
# Allow guestx user to remote poweroff
guestx ALL=(ALL) !ALL
guestx ALL=NOPASSWD: /sbin/poweroff
Traduction :interdire toutes les commandes, puis autoriser uniquement la commande souhaitée (sans demander de mot de passe dans ce cas).
Avec cette configuration, sudo demande le mot de passe puis échoue pour les commandes autres que celle en liste blanche :
[email protected]:~$ sudo su -
Password:
Sorry, user guestx is not allowed to execute '/bin/su -' as root on ds.
[email protected]:~$