Discussion:Sudo

.. sudo et gksu et kdesu..

gksu et kdesu sont deux implémentations de la commande sudo. La présentation des trois produits dans un seul article faciliterais la lecture. Silex6 (d) 7 septembre 2012 à 12:48 (CEST)[répondre]

1. Contre Rien à voir en ce qui concerne kdesu qui est un frontend pour su et non sudo, lien limité en ce qui concerne gksu qui est un frontend à la fois pour su et sudo. Amicalement — Arkanosis ^✉ 8 septembre 2012 à 21:42 (CEST)[répondre]
2. Contre j'ajouterai qu'il existe un kdesudo. Éventuellement pour une vaste fusion entre su, sudo, kdesu, kdesudo et gksu dans un article-chapeau au titre à déterminer ("su et sudo" ?). --MathsPoetry (d) 9 septembre 2012 à 16:59 (CEST)[répondre]
3. Contre idem, pas de raison d'associer "sudo" et pas "su". Voir aussi la solution de en: en:Comparison of privilege authorization features (mais su et sudo survivent). Proz (d) 9 septembre 2012 à 22:03 (CEST)[répondre]

   Pour la proposition de MathsPoetry, d'une fusion d'ensemble de su, sudo, kdesu, kdesudo et gksu. Je constate de plus que dans l'article en:Comparison of privilege authorization features - qui traite non seulement Unix, mais aussi d'autres OS - ils sont traités ensemble dans les mêmes paragraphes.--Silex6 (d) 10 septembre 2012 à 12:13 (CEST)[répondre]

   en:Comparison of privilege authorization features peut très bien être le fameux article-chapeau. Je n'aime que moyennement "comparison" dans le titre, qui pourrait être plus simple. Quelque chose comme "Augmentation des privilèges (informatique)" ou "Élévation de privilèges (informatique)". Si on manque de temps, on peut restreindre le champ à UNIX. --MathsPoetry (d)

   Il existe déjà un article élévation des privilèges dans le portail de la sécurité informatique. Rien n'empêche d'y ajouter les différentes commandes Unix, et d'étoffer l'article avec des fonctions équivalentes sur d'autres OS.--Silex6 (d) 10 septembre 2012 à 22:18 (CEST)[répondre]

   Pffff, pour le coup ce sont les anglophones qui devraient fusionner en:Comparison of privilege authorization features et en:Privilege escalation. Je crois qu'on est sur la bonne voie, mais ça devient le b... pour l'aspect pratique. Et en tout état de cause, quand on aura la bonne solution, il faudra recommencer une procédure de PàF sur les nouvelles bases . --MathsPoetry (d) 10 septembre 2012 à 22:23 (CEST)[répondre]

   fait au même instant (et conflit d'édition).--Silex6 (d) 10 septembre 2012 à 22:31 (CEST)[répondre]

.. Élévation des privilèges et Su (Unix) et sudo et gksu et kdesu .. Suite à la discussion précédente, je propose la fusion de différents articles concernant des commandes d'élévation de privilège dans l'article élévation des privilèges.--Silex6 (d) 10 septembre 2012 à 22:31 (CEST)[répondre]

1. Pour (si ce n'est pas moi qui m'y colle, car j'ai ma dose de fusions). Ne pas oublier les mécanismes d'élévation de Windows et de Mac OS X, ni ce pauvre kdesudo qui n'a pas d'article. --MathsPoetry (d) 10 septembre 2012 à 22:33 (CEST)[répondre]
2. Contre l'avis de fusionner su (unix) avec le reste ; su ne permet aucune élévation de privilèges, c'est une composante du système qui permet de se loguer en tant que superuser... c'est un logiciel système, les autres sont des logiciels utilitaires... ; on ne peut pas fusionner une composante du système avec des interfaces utilisateurs, ce sont des choses différentes ; on ne traite pas l'admissibilité des articles par des procédures de fusion ; perso, j'utilise emacs, on ne va pas pour autant fusionner emacs et su (#!genium ✉) 11 septembre 2012 à 02:11 (CEST)[répondre]

   Non. Tu confonds « se loguer en tant que » et « endosser l'identité de ». Tu restes logué en tant que toi-même quand tu fais un su, je t'encourage à le vérifier, par exemple avec la commande who am i. Comment tout cela fonctionne-t-il ? su a le bit setuid, tandis que kdesu n'est qu'un wrapper graphique autour de su. Au final il n'y a qu'un seul mécanisme mis en jeu, directement ou indirectement, c'est celui du bit setuid. su n'est pas une composante du système, c'est un utilitaire qui saisit un mot de passe et le vérifie, et si le mot de passe est correct il lance un shell ou une commande : toute la « magie » est dans le bit setuid.

   Cela étant dit, on peut aussi présenter ces programmes pour ce qu'ils sont, des utilitaires, dans un article fusionné. C'est justement l'occasion de présenter toute cette mécanique. --MathsPoetry (d) 11 septembre 2012 à 09:32 (CEST)[répondre]

   Heu, j'ai mis se loguer en italique, j'aurais dû mettre des guillemets... ce que je voulais dire, c'est que les commandes apparaissent dans les logs de l'utilisateur root, pas dans celui du user... pour moi, su est une composante du système, la commande est disponible quand on installe le système à partir des sources (avant l'installation du noyau et la création d'un utilisateur), on peut l'appeler utilitaire système si tu préfères, elle est d'ailleurs maintenue par le projet GNU Core Utilities dans le système GNU et ses variantes GNU/Linux ; je doute par ailleurs de l'admissibilité de gksu et kdesu qui sont des interfaces utilisateurs... (#!genium ✉) 11 septembre 2012 à 11:37 (CEST)[répondre]

   OK, pas de souci. utilitaire système est effectivement le bon terme, même s'il est rangé sous /bin et pas sous /sbin (ce qui est d'ailleurs bizarre, à mon avis). su est aussi une interface utilisateur (en mode texte), la preuve en est qu'il refuse de fonctionner s'il n'est pas attaché à un tty (tant et si bien que kdesu est obligé de tricher en lui créant un pseudo-tty !). Mais je pinaille. --MathsPoetry (d) 11 septembre 2012 à 12:11 (CEST)[répondre]

3. Contre Domaine trop vaste ÀMHA — Arkanosis ^✉ 11 septembre 2012 à 11:57 (CEST)[répondre]

Je reste convaincu qu'il n'y a pas lieu de faire un article sur chaque commande UNIX. Cela étant, un tel article fusionné risque d'être trop gros et illisible, ici on a beaucoup de matière. Est-ce que la façon prudente de procéder n'est pas d'y aller en deux temps, d'abord améliorer "Élévation de privilèges", et ensuite seulement voir ce qu'il y a lieu de fusionner ? --MathsPoetry (d) 11 septembre 2012 à 10:12 (CEST)[répondre]

(Réponses un peu hors sujet ici, su permet aussi se "logger", option "-", /sbin n'est pas par défaut dans le path des simples utilisateurs sur les systèmes que je fréquente donc il est normal que "su" n'y soit pas classée). J'avoue que je découvre ces propositions de fusion par cette page (à l'occasion d'une autre demande en math), et les pages afférentes du même coup. J'ai réagi ici et là comme simple utilisateur de système unix, et de la distribution debian en particulier depuis pas mal de temps, mais sans trop avoir l'intention de m'investir fortement dans l'édition de ces articles. Je crois comprendre que le problème est la multiplication d'articles croupions assez indigents (gksu), de contenu non encyclopédique (kdesu), le ton parfois exagérément publicitaire (fin de l'intro de Advanced Packaging Tool), sans potentiel de développement. Mais ces demandes de fusions semblent lancées un peu à l'aveugle, et nécessiteraient un débat préalable (qui n'est pas très commode ici). N'y-a-t-il pas une page de projet où en discuter ? Je débarque, donc vous voudrez bien m'excuser si je passe complètement à côté de quelque chose, mais je suis un peu surpris. Mon avis et que vu que les forces éditoriales semblent assez réduites, il vaudrait mieux suivre autant que possible la wikipedia en: (où c'est loin d'être parfait, mais il y a quand même plus de choses intéressantes), et ne pas trop bouleverser. En l'occurrence, même si une fusion n'est pas inenvisageable, l'existence de deux articles su et sudo ne parait pas inconvenante non plus (histoire plus ancienne pour su, usages qui ne se recouvrent pas vraiment), coïncide avec en:, et surtout il n'y a rien à faire de plus. Par contre pour kdesu, kdesudo, et gksu une simple mention, ou un paragraphe sur l'un ou sur les deux articles pourrait suffire, en attendant une traduction éventuelle ou un équivalent de en:Comparison of privilege authorization features (article pas sans intérêt) et dont le sujet n'est manifestement pas le même que celui de en:Privilege escalation ("feature" faisant la différence), avec fusion sur l'un ou l'autre, et ama, vu le contenu, ça n'a même pas besoin de passer ici (cf. Aide:Fusion) s'il y a accord au niveau du projet (lProjet:Informatique je suppose ?). Proz (d) 11 septembre 2012 à 15:22 (CEST)[répondre]

Réponse courte: en effet cette succession de proposition de fusions n'est pas une simple coïncidence. Si il est préférable de lancer un débat de fond, c'est à faire sur la page de discussion du projet Informatique.--Silex6 (d) 11 septembre 2012 à 15:44 (CEST)[répondre]

(hors-sujet) Tu as raison pour /sbin et le chemin. J'aurais dû y penser.

Tu as tort pour "se loguer". « Se loguer » signifie se connecter au système. Quand tu te connectes au système, ton nom apparaît alors dans les journaux de connexion au système, qui n'ont rien à voir avec les journaux des commandes saisies. Tape par exemple lastlog pour faire apparaître la date de dernière connexion de root, tu verras qu'elle n'est pas influencée par les éventuels su. Enfin, l'option "-" de su sert à utiliser l'environnement de l'utilisateur dont tu endosses l'identité, comme si tu t'étais logué sur ce compte. Regarde sur la page de manuel de su, ce « comme si » est important. Tout le monde sous UNIX a en permanence deux identités, l'identité réelle et l'identité effective, et su ne change que l'identité effective, comme expliqué par Olaf Kirch ici. --MathsPoetry (d) 12 septembre 2012 à 12:51 (CEST)[répondre]

réponse sur ta pdd pour ne pas prolonger ici le hors sujet. Proz (d) 14 septembre 2012 à 00:46 (CEST)[répondre]

1.  Plutôt contre, au moins pour l’article élévation des privilèges, qui est un principe assez général, avec les logiciels qui peuvent le mettre en oeuvre. D’ailleurs j’imagine qu’on peut utiliser sudo pour faire de l’abandon de privilèges si on veut … TomT0m (d) 14 septembre 2012 à 12:37 (CEST)[répondre]