Discussion :

[imperio]

Pas la fonction, celui du chmod : http://fr.wikipedia.org/wiki/Setuid

EDIT : Et c'est la même chose pour la fonction dans tous les cas...

EDIT2 : et ta dernière remarque est justement la raison pour laquelle rm n'est ni en setuid, ni en setgid

Je connaissais pas du tout ! Je comprends mieux maintenant... C'est vachement dangereux ce truc ! Cependant le problème reste si le fichier n'est lisible que pour le root et que l'utilisateur peut devenir root. Dans tous les cas je ne vois pas du tout à quoi ça pourrait lui servir...

[Metalman]

Ce qu'on lui propose, mais c'est à BIEN réfléchir :

- Il créer un exécutable qui appartient à un utilisateur (non-root) qui aura le droit de lire les scripts (les scripts appartiendront donc à un utilisateur virtuel)
- Cet exécutable appartiendra à un groupe dont tous les gens, qui ont besoin d'exécuter des scripts, appartiennent (en groupes secondaires)
- Exécutable en SetUID + Autorisé pour le groupe UNIQUEMENT + Limitation des commandes passées (pour n'autoriser QUE les scripts référencés)

Le problème reste celui que kwariz soulève : quelle est la réelle raison de cacher la lecture des scripts aux utilisateurs ?

EDIT : On n'est pas obligé de SetUID avec root dans tous les cas

EDIT2 : mais attention, on propose du chmod... avec les ACL il y a peut être moyen de faire mieux...

[Metalman]

Comme c'est la mode des petits dessins...
J'ai résumé ma proposition avec un ajout "utile" :

- Une application (le fameux wrapper C) qui servira de "proxy de scripts".
L'utilisateur virtuel sera le propriétaire, et "groupe_lecture" sera son groupe.
Le chmod 4750 permet :

• 4 => SetUID, on va devenir l'utilisateur virtuel à l'exécution
• 7 => Tous les droits pour l'utilisateur virtuel sur sa propre application
• 5 => Le groupe_lecture peut lancer cette application
• 0 => Le reste ne peut rien faire

- Les scripts, seront possédés par l'utilisateur virtuel, et auront comme groupe "groupe_ecriture". Seuls les membres de ce groupe pourront écrire dans les scripts. Le dossier de scripts sera évidemment avec les même droits.
Le chmod 1570 permet :

• 1 => StickyBit, seul le propriétaire peut supprimer le fichier (mais on peut le vider quand même il me semble... à vous d'avoir un FS à journalisation dans ce cas, ou des backups réguliers), et uniquement le proprio ! Pas le groupe.
• 5 => L'utilisateur virtuel ne pourra pas écrire dedans (ça ne sert pas tellement, mais on peut surveiller des comportements anormaux si ce droit change sans que cela n'ait été prévu)
• 7 => Le groupe_ecriture peut tout faire dessus, amis le sticky bit empêche la suppression (à vous de mettre en place un système bien organisé autour pour faire des demandes de suppression/ajout)
• 0 => Le reste ne peut rien faire

Les groupes :
- groupe_lecture contiendra tous les gens qui ont besoin d'exécuter les scripts sans les lire (bon ok, le nom est mal choisi), et pourquoi pas ceux qui les écrivent.
- groupe_ecriture contiendra uniquement ceux qui peuvent écrire les scripts

Pour le programme de "proxy de scripts", il faudra de préférence écrire en dur dedans les scripts autorisés, ou lire depuis une liste les scripts autorisés (donc liste en chmod 500 + fopen en O_RDONLY dessus), et n'exécuter QUE les scripts disponibles avec le moins d'intéractions utilisateurs possibles.
Par exemple :
./proxy_de_scripts script.sh "mes arguments"
ou
./proxy_de_scripts script.sh arg1 arg2

Et il suffira de recréer la liste d'arguments et la passer à exec.

Voilà.
Si quelqu'un a mieux, qu'il le propose.