Je ne pense pas que tu aies réellement pris le soin de lire ce qu'il a derrière les liens que j'ai posté mais bon. Cela n'a pas beaucoup d'importance. Je crois surtout que la majorité des applications n'ont pas forcément besoin d'être lancées sous root plutôt que sous un pseudo-utilisateur lambda. Le meilleur exemple, même en setuid, est celui de la commande passwd : Elle est historiquement setuidée root et ce depuis l'aube de l'histoire d'UNIX, alors qu'elle se contente de modifier un fichier texte (/etc/password). Même avec l'apparition de PAM, un setgid suffirait, avec un groupe dédié qui n'a pas besoin d'être celui de root.
Pour obtenir un outil équivalent à synaptic en console, il faut lancer aptitude avec son interface ncurses, donc tant que tu n'as pas fini, l'application aura les privilèges de root. Donc, tu n'aimes pas simplement gksudo (plutôt que sudo) mais carrément l'idée qu'on puisse offrir des outils d'administration via des clients X11. Que proposes-tu à la place ?
Une application X ne devrait jamais avoir besoin d'être exécutée sous le compte root ! Pas plus qu'aptitude d'ailleurs. La promotion au compte n°0 ne devrait avoir lieu qu'au moment d'appliquer les modifications réclamées. Apache, par exemple, fait cela proprement en gardant un seul processus root initial et en gardant ses threads sous sa propre identité.
Mieux : dans le cas de proftpd cité en exemple, le gars voulait carrément virer le mot de passe du superchef, comme il dit, alors qu'en creusant un peu, on s'aperçoit qu'aucun composant (depuis le serveur jusqu'à l'interface de configuration) n'a réellement besoin d'être root ou de lui appartenir.
Ubuntu n'est certainement pas encore parfaite mais, par rapport aux autres distributions, c'est la seule qui propose l'usage de sudo (et gksudo) par défaut ce qui permet d'utiliser des interfaces graphiques sans nécessiter de taper un mot de passe root que les débutants auraient tôt fait d'y mettre la même chose que pour leur utilisateur. On touche là finalement un problème humain plutôt que technique. La réponse ne peut donc être simplement technique.
Soit, grosso-modo, ce que j'expliquais dans mon précédent post.
L'une des choses qui me dérangent le plus actuellement, c'est la conservation du délai de grâce par gksudo. Sudo gère déjà cela mais au moins, l'utilisateur doit taper explicitement la commande, ce qui implique à priori qu'il sait de quoi il s'agit, mais surtout, cette période est accordée uniquement à la console de travail. Depuis X, le lock est créé en tant que unknown, ce qui signifie que gksudo peut ensuite être lancé de façon transparente et silencieuse non seulement depuis l'environnement X, mais également depuis n'importe quel processus qui aurait daemonisé et se serait détaché de sa console.
[^] # Re: Parc linux non homogéne
Posté par Obsidian . En réponse à la dépêche Les virus sous Linux. Évalué à 5.
Une application X ne devrait jamais avoir besoin d'être exécutée sous le compte root ! Pas plus qu'aptitude d'ailleurs. La promotion au compte n°0 ne devrait avoir lieu qu'au moment d'appliquer les modifications réclamées. Apache, par exemple, fait cela proprement en gardant un seul processus root initial et en gardant ses threads sous sa propre identité.
Mieux : dans le cas de proftpd cité en exemple, le gars voulait carrément virer le mot de passe du superchef, comme il dit, alors qu'en creusant un peu, on s'aperçoit qu'aucun composant (depuis le serveur jusqu'à l'interface de configuration) n'a réellement besoin d'être root ou de lui appartenir.
Soit, grosso-modo, ce que j'expliquais dans mon précédent post.
L'une des choses qui me dérangent le plus actuellement, c'est la conservation du délai de grâce par gksudo. Sudo gère déjà cela mais au moins, l'utilisateur doit taper explicitement la commande, ce qui implique à priori qu'il sait de quoi il s'agit, mais surtout, cette période est accordée uniquement à la console de travail. Depuis X, le lock est créé en tant que unknown, ce qui signifie que gksudo peut ensuite être lancé de façon transparente et silencieuse non seulement depuis l'environnement X, mais également depuis n'importe quel processus qui aurait daemonisé et se serait détaché de sa console.