Discussion :

[Catskan]

Bonjour à tous,

Je fais appel à vous car je bloque sur une étape de mon programme.
Je suis en train de faire une programme qui me permet d'éxécuter des commandes shell en cliquant sur des boutons.
Mais lorsque j'ai besoin d'éxécuter une commande en sudo, le programme plante.
J'ai essayé de faire un bouton avec la commande sudo et le mot de passe "en dur" mais impossible.
J'ai l'impression qu'il sort du shell ou qu'il ne m'écrit pas le mot de passe lorsqu'il le demande.

Savez-vous comment puis-je faire pour executer des commandes sudo ?

Merci d'avance pour votre aide.

[Obsidian]

Bonjour,

On suppose donc que tu travailles sous Unix ou sous Linux.

Ce n'est absolument à ton programme binaire d'appeler sudo lui-même. Ce serait une une grosse faille de sécurité. De plus, sudo, bien que très répandu, n'est pas une commande fondamentale mais un utilitaire, soumis à ses propres règles et ses fichiers de configuration.

Enfin, si tu cherches à appeler sudo, c'est que tu cherches à lancer un programme en tant que root et même là, cela doit se justifier. 90 % des débutants cherchent à faire cela pour contourner une limitation gênante plutôt que se demander pourquoi cette limitation est en vigueur.

Dis-nous ce que tu cherches à faire exactement au final.

[Catskan]

Par exemple, je dois executer la commande " sudo ifconfig en1 lladdr 00:00:00:00:00:00"
Mais pour cela il faut obligatoirement être authenfier en sudo pour l'exécuter ...
Il y a un autre moyen plus fiable ?

[Klaim]

Ce que tu cherches c'est les fonctions pour changer le niveau d'accès (demander a ce que ce soit un administrateur qui execute ton appli). Ce sont des fonctions dépendantes de l'OS, pas du language C++ ou C.

[Obsidian]

Par exemple, je dois executer la commande " sudo ifconfig en1 lladdr 00:00:00:00:00:00"
Mais pour cela il faut obligatoirement être authenfier en sudo pour l'exécuter ...
Il y a un autre moyen plus fiable ?

Ce que tu cherches c'est les fonctions pour changer le niveau d'accès (demander a ce que ce soit un administrateur qui execute ton appli). Ce sont des fonctions dépendantes de l'OS, pas du language C++ ou C.

Autrement dit : c'est à l'utilisateur d'appeler ton programme avec sudo, ou en tant que root. Ce n'est pas à ton logiciel d'aller acquérir ces privilèges seuls.

En principe, tu dois également te contenter de renvoyer le message d'erreur correspondant au code que tu reçois lorsqu'elle se produit. Tu peux à la limite préciser « need to be root » entre parenthèses, mais seulement si tu sais absolument ce que tu fais, car il est possible, notamment via les « capabilities », de conserver certains pouvoirs même en abandonnant l'identité root.

D'autre part, si tu codes en C ou en C++, c'est pour faire de la programmation système. Donc appeler une commande shell depuis un programme exécutable en langage machine, c'est passablement sale.

[Catskan]

Oui mais comment faire pour que l'utilisateur s'identifie ?
Il faut forcément entrer le mot de passe dans le programme non ? Ca je voudrai pas qu'il lance un Terminal pour que l'utilisateur entre son mot de passe.
Le programme ne servira qu'à moi de toute façon.
Ca fait 2h que j'éssaie de faire fonctionner cette commande qui a besoin d'être authentifié mais sans succès .

[Obsidian]

Oui mais comment faire pour que l'utilisateur s'identifie ?
Il faut forcément entrer le mot de passe dans le programme non ? Ca je voudrai pas qu'il lance un Terminal pour que l'utilisateur entre son mot de passe.

Ça dépend du système d'exploitation et de l'environnement choisi par l'utilisateur et c'est à lui de voir cela. Pas à toi. Au pire, si c'est toi qui te charges de faire le package pour ta distribution, il faudrait voir quels sont les sont les procédés mis en place par le bureau graphique pour faire cela. Sous Gnome 3, par exemple, il y a pkexec.

Il y a aussi les bits setuid et setgid qui sont la manière officielle, sous Unix, de lancer automatiquement un programme avec une identité donnée (généralement root mais pas forcément). Mais il faut absolument justifier leur utilisation.

Le programme ne servira qu'à moi de toute façon. Ca fait 2h que j'éssaie de faire fonctionner cette commande qui a besoin d'être authentifié mais sans succès .

C'est normal parce que ce n'est pas de cette manière qu'il faut procéder.
Encore une fois : que cherches-tu à faire au final ?

[Catskan]

Je suis sous OS X donc je pense que je dois bits setuid et setgid.
Au final, je veux qu'en cliquant sur des boutons il m'execute les commandes souhaitées.

Par exemple : Charger adresse mac : sudo ifconfig en1 lladdr 00:00:00:00:00:00
Purger mémoire : purge ...

Les commandes sans avoir besoin d'être administrateur fonctionnent parfaitement.
Pour le moment la seule commande que j'ai sous la main pour laquelle il faut être root est celle de l'adresse mac.

[Klaim]

Ce que tu n'as pas l'air de comprendre c'est que ici "sudo" est une application qui va, une fois qu'il aura vérifié que l'utilisateur est super-user, executer le reste de la ligne de commande en tant que root.

Donc en gros, l'application elle même ne fais pas la demande d emots de passet etc. Au mieu, comme dis au dessus, elle repère qu'elle n'a pas de droits d'accès pour faire son boulot et sois gère ce cas, soit juste affiche le probleme et quitte.

[Emmanuel Deloget]

Oui mais comment faire pour que l'utilisateur s'identifie ?
Il faut forcément entrer le mot de passe dans le programme non ? Ca je voudrai pas qu'il lance un Terminal pour que l'utilisateur entre son mot de passe.
Le programme ne servira qu'à moi de toute façon.
Ca fait 2h que j'éssaie de faire fonctionner cette commande qui a besoin d'être authentifié mais sans succès .

Si le programme ne sert qu'à toi, pourquoi ne pas le lancer en tant que root ? Une autre solution serait de mettre l'owner/group à root:root et de rajouter le bit setuid sur le programme - de cette manière, il n'aura pas besoin de faire de sudo. Je ne vois pas réellement de problème ici : une fois en setuid root:root, ton programme pourra appeler ifconfig sans avoir besoin de faire un sudo (normallement).

[ternel]

D'une manière générale, la gestion des droits n'est pas l'affaire du programme, mais de l'admin qui l'a installé.

Ce n'est pas une bidouille quelconque dans le code qui sera valable, aussi "belle" soit-elle.

[Obsidian]

Une autre solution serait de mettre l'owner/group à root:root et de rajouter le bit setuid sur le programme - de cette manière, il n'aura pas besoin de faire de sudo.

C'est ce que l'on a dit plus haut, mais j'aimerais être sûr que c'est parfaitement justifié avant de lui faire prendre l'habitude d'y recourir (même si c'est toujours mieux qu'un « system("sudo"); »).

Si c'était un tout petit utilitaire console, à la limite, mais il parle d'une application graphique avec des boutons, etc. qui s'appuie probablement elle-même sur un framework particulier pour les générer facilement. Lancer tout cela sous root de manière systématique et transparente, ça me dérange un peu.

[Emmanuel Deloget]

D'une manière générale, la gestion des droits n'est pas l'affaire du programme, mais de l'admin qui l'a installé.

Ce n'est pas une bidouille quelconque dans le code qui sera valable, aussi "belle" soit-elle.

C'est à la fois vrai, à la fois faux. Si c'était complètement vrai alors le programme sudo n'aurait pas de fichier de configuration : c'est bien le programme qui, une fois sa configuration lue, décide quoi faire (même si le fichier en question est défini par l'administrateur, c'est le programme qui prends ses décisions). Mais en même temps, sudo (et les programmes/mécanismes similaires sur d'autres OS, telle l'impersonnation sur Windows) fait un peu figure d'exception.

C'est ce que l'on a dit plus haut, mais j'aimerais être sûr que c'est parfaitement justifié avant de lui faire prendre l'habitude d'y recourir (même si c'est toujours mieux qu'un « system("sudo"); »).

Si c'était un tout petit utilitaire console, à la limite, mais il parle d'une application graphique avec des boutons, etc. qui s'appuie probablement elle-même sur un framework particulier pour les générer facilement. Lancer tout cela sous root de manière systématique et transparente, ça me dérange un peu.

Au final, il faut savoir ce que tu veux

Si tu distribuait ton programme, ça serait un gros NON tout de suite. La plupart des framework graphiques sont trop important et cachent de nombreux problèmes de sécurité (buffer overflow exploitables, etc...). Mais si tu le garde pour toi uniquement, alors tu as cette possibilité - parce qu'utiliser un vecteur d'attaque ne peut se faire que si le vecteur d'attaque est connu, et en le gardant pour toi, tu n'a aucune chance qu'un attaquant puisse le découvrir.

Tu peut en outre conditionner l'exécution du programme, en testant l'uid et le gid de celui qui lance le programme (un process possède un uid, un gid, un euid (effective uid) et un egid (effective gid)).

Code getuid.c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
#include <unistd.h>
#include <stdio.h>
#include <sys/types.h>
 
int main()
{
	uid_t uid, euid;
	gid_t gid, egid;
 
	uid = getuid();
	euid = geteuid();
 
	gid = getgid();
	egid = getegid();
 
	printf("uid = %d ; euid = %d\ngid = %d ; egid = %d\n", 
		uid, euid, gid, egid);
 
	return 0;
}

Code shell :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
$ gcc -o getuid getuid.c
$ ls -l
-rwxr-xr-x 1 edt  edt  7364 oct.   5 11:52 getuid*
-rw-r--r-- 1 edt  edt   286 oct.   5 11:52 getuid.c
$ ./getuid
uid = 2039 ; euid = 2039
gid = 2039 ; egid = 2039
$ sudo su
# chown root:root getuid
# chmod +s getgid
# exit
$ ls -l
-rwsr-sr-x 1 root root 7364 oct.   5 11:52 getuid*
-rw-r--r-- 1 edt  edt   286 oct.   5 11:52 getuid.c
$ ./getuid
uid = 2039 ; euid = 0
gid = 2039 ; egid = 0

Bref, en testant l'uid et le gid du lanceur du programme, tu peux très simplement restreindre l'utilisation de ton programme, dès les premières lignes de main(), et donc priver un pirate de la possibilité d'exécuter ton programme (sauf s'il parvient à le lancer depuis ton compte, auquel cas, il peut l'exécuter comme s'il était toi).