[Admin-ml] Un script shell avec sudo...

[Proniewski Patrick]

On 21 nov. 07, at 07:52, Piel Jayce wrote:

> Imagine un peu un utilisateur qui apprend à se servir du sudoers,  
> il sait pas trop comment le configurer, et ne sait pas par exemple  
> que l'on peut limiter les droits d'exécution d'une commande à un  
> groupe ou une personne.

si il ne sait pas ça, c'est qu'il n'apprend pas à se servir de sudo.  
Le problème est entre la chaise et le clavier. sudo n'introduit en  
l'occurence aucun trou de sécurité, dans la mesure où, de toute  
manière, l'utilisateur est déjà root de sa machine. Qu'il fasse des  
bêtises avec sudo, avec rm, ou avec autre chose, le problème est le  
même : l'éducation de l'administrateur.


 >> l'utilisation de la crontab aussi, mais y'a moins de risque de  
faire des bêtises.
>>
>> oui enfin là, quand tu as des routines à lancer périodiquement,  
>> y'a pas des masses le choix :)
>
> En l'occurence, si j'ai bien compris le message d'origine, il  
> voulait lancer un script régulièrement, mais comme certains bouts  
> de son script ont besoin des droits root, il voulait pouvoir lancer  
> des sudo dans son script sans avoir à taper le mot de passe.
> Je le répète, dans ce cas là, l'utilisation de la crontab système  
> ou d'un dayly.local est beaucoup plus appropriée que la  
> modification du sudoers...


pas forcément !
lancer un script en root n'est pas la solution unique, ni  
systématiquement la meilleure à un problème comme celui là. Tu peux  
vouloir rester entièrement dans le domaine d'autorisation de  
l'utilisateur, en lui gardant ses droits sur les fichiers et tout et  
tout, sans avoir à rajouter des umask/chmod/chown toutes les 2 ou 3  
lignes de script, sous prétexte que tu préfères le lancer en root  
d'un bout à l'autre.
Je prends un exemple réèl :
J'ai la crontab suivante pour mon user "patpro" :

# Collect system information every minute
* * * * *       /usr/local/www/admin/bgraphs/memory.sh >/dev/null
* * * * *       /usr/local/www/admin/bgraphs/disk_usage.sh >/dev/null
* * * * *       /usr/local/www/admin/bgraphs/network_usage.sh >/dev/null
* * * * *       /usr/local/www/admin/bgraphs/temperature.sh >/dev/null
# Status graphs generation
*/15 * * * *    /usr/local/www/admin/bgraphs/network_usage_graphs.sh  
 >/dev/null
*/15 * * * *    /usr/local/www/admin/bgraphs/disk_usage_graphs.sh >/ 
dev/null
*/15 * * * *    /usr/local/www/admin/bgraphs/memory_graphs.sh >/dev/null
*/15 * * * *    /usr/local/www/admin/bgraphs/temperature_graphs.sh >/ 
dev/null

Ce sont des scripts qui remplissent des bases RRDTool avec des vitals  
du système. Les fichiers associés (scripts, bases rrd, graph  
générés, ...) appartiennent tous à l'utilisateur "patpro", et je ne  
souhaite pas que les scripts soient lancés en root (car cela ne sert  
à rien, et donc c'est plus sûr qu'ils ne soient pas lancés en root).
Seulement, le script temperature.sh utilise le binaire `healthd` qui  
ne peut être lancé que par root, à cause d'une sombre histoire  
d'accès à un device.

Dans mon sudoer j'ai ajouté :

patpro  ALL=(ALL) PASSWD: ALL, !/usr/local/sbin/healthd, NOPASSWD: / 
usr/local/sbin/healthd

Ce qui signifie que le user "patpro" peut faire sudo pour toutes les  
commandes, que sudo lui demandera son mot de passe pour toutes les  
commandes, SAUF pour /usr/local/sbin/healthd. Pour ce dernier, pas de  
mot de passe à saisir.

Mon script temperature.sh contient donc la ligne :

TEMPERATURE=`sudo /usr/local/sbin/healthd -c 1 | awk 'blahblah'`

Ce qui permet à ma crontab de lancer en root uniquement les commandes  
qui en ont besoin, tout en laissant tout le reste tourner avec les  
privilèges de "patpro".

Patrick PRONIEWSKI
-- 
Administrateur Système - SENTIER - Université Lumière Lyon 2

-------------- section suivante --------------
Une pièce jointe non texte a été nettoyée...
Nom: smime.p7s
Type: application/pkcs7-signature
Taille: 2447 octets
Desc: non disponible
Url: http://coruscant.mosx.org/pipermail/admin-ml/attachments/20071121/b6981e43/smime.bin