Ou peut-être que c'est le logo de Windows qui ressemble un peu trop aux couleurs primaires (ce qui revient pratiquement à dire qu'il ne ressemble à rien).
Quand j'étais au lycée, j'avais un prof' principal qui, lui, visait 100% de réussite au bac, ce qui nous faisait doucement sourire. On a beaucoup moins rigolé quand on s'est rendu compte qu'il s'arrangeait pour éjecter au cours de l'année les élèves qui, selon lui, n'aurait apparement pas le niveau au jour J. Pour le reste, j'ai eu la même année des enseignants formidables qui, outre la qualité de leurs cours, ont été les premiers à sonner l'alarme quand j'ai commencé à être très en difficulté.
Bref, être professeur, plus que n'importe quel autre métier, se doit d'être une vocation. Malheureusement, comme dans toute filière, on aura des carriéristes qui porteront préjudice à leurs élèves.
C'est pour cela que je refuse de jeter l'anathème sur le système scolaire en général, même s'il m'a beaucoup déçu à certaines époques. Ensiegner n'est pas facile et, même dans la plus pourrie des écoles de quartier, il y a toujours un enseignant qui fait son travail avec beaucoup de conscience et qu'il faut soutenir.
Vouloir le meilleur pour ses enfants est parfaitement normal et j'en ferais autant, mais le problème de " l'attitude consumériste ", selon moi, c'est que l'on sait très bien que de cette manière, il n'y aura pas de place pour tout le monde. Faire jouer la concurrence n'est valable que si toutes les écoles deviennent privées, et ce n'est pas souhaitable. Même les familles les plus aisées devraient avoir le droit à un enseignement public de qualité, au même titre que tous les autres.
Le vrai problème est de pouvoir s'impliquer dans la vie de l'école, en tant qu'élève ou en tant que parent d'élève, pour pouvoir y faire changer les choses quant elles ont réellement besoin de l'être. Et notamment, trouver des financements.
Je n'ai rien contre le fait de "pousser les murs" des écoles privées en soi, si ce n'est que cela risque de conduire à la fermeture de plus de classes et d'écoles, avec des gamins obligés de faire 40 kms par jour par rallier la plus proche. Et tout cela sans garantie que les programmes privés tiennent leurs promesses.
Si tu as utilisé les fonctions d'une bibliothèque en C, il faut retrouver une bibliothèque équivalente en Perl.
Si tu as utilisé les séquences CSI avec Escape, il suffit de rebalancer les mêmes à l'écran puisque c'est le terminal qui gère sa surbrillance, pas directement le programme en lui-même ...
Mouais, ce serait bien mais les gens vont plutôt se dire "ODP ? Je connais pas. Ca doit être comme avec les *.PIF. Cai surement un virusse qui essaie de s'introduire".
Ca reste très laid. Comme "supporter". Il y a de fortes chances pour que ce terme ait été introduit exactement dans les mêmes conditions qu'aujourd'hui :la "légalisation" d'une mauvaise habitude.
Personnellement, je commence à me méfier des dictionnaires. Ils sont tenus comme étant la référence absolue et indiscutée de ce qui est valable ou non en français, alors que personne ne sait réellement qui les définit.
Ce qui m'ennuie particulièrement, c'est qu'il s'agit en général des mêmes personnes qui, sous prétexte de parler une langue "vivante", en profitent pour y ajouter n'importe quoi. C'est dans le même esprit que les effets de mode temporaires et surtout anglicismes mal traduits propre à un jargon particulier (spécialement vrai en informatique) se retrouvent édités dans un souci d'exhaustivité, simplement pour être plus efficace que le concurrent.
A la limite, je n'ai rien contre çà tant que cela s'en tient à la fonction première du dictionnaire : définir un mot dont on ignore le sens. Par contre, je pense qu'il est vital de repérer ces mots comme néologismes, jargon et autre et de bien préciser qu'ils ne doivent pas, à priori, être utilisés dans le langage courant.
Surtout quand la plupart de ces djeunz ne sont, de toutes façons, même pas capables d'utiliser correctement ces verbes du premier groupe ("er-é"). Personnellement, je n'arrive pas à m'y faire. Je trouve qu'à chaque jour qui passe, ça pique un peu plus les yeux encore.
Oui, enfin, çà, c'est une pente savonneuse : c'est exactement le discours que tiennent les adeptes de chez Redmond. Si le système ne marche pas, c'est parce que tu ne l'utilise pas correctement. Un peu facile.
Par défaut, un bon système devrait être blindé contre les erreurs de débutants. Après, si le gars fait des conneries en sudo, ben ça le regarde ... pour autant qu'il ne soit pas systématiquement obligé de passer par là pour effectuer des tâches d'administration régulières !
Merci bien! je n'avais pas la certitude qu'il s'agissait des memes opérateurs.
C'est curieux quand même. C'est toujours une très bonne chose de demander mais, en l'occurence, le plus simple, c'était encore d'essayer, n'est-ce-pas ?
Oui, enfin, les portables ont l'avantage de ne pas faire de bruit, de ne pas prendre de place, d'être aujourd'hui pratiquement tous équipés en Wifi comme d'une carte 3D et d'être pour ainsi dire aussi puissants que les tours de bureau.
C'est idéal quand on habite dans un petit appartement par exemple. En plus, comme on peut le trimballer partout, on évite en général d'avoir à synchroniser ses machines. Le seul inconvénient, c'est qu'ils sont très peu évolutifs, et que l'on ne peut pas y mettre une carte 3D à refroidissement par eau :-) Dans le premier cas de figure, j'ai tendance à dire que cela ne pénalise ni ceux qui changent fréquemment de config', ni ceux qui gardent la même pendant 10 ans.
La seule chose que je recommande, c'est la possibilté de le docker dans une station d'accueil.
Journal : Comment surprendre agréablement votre femme ? Lui dire que vous allez vous acheter des vêtements ! Alors que d'habitude, c'est elle qui se bat pour vous emmener acheter un pantalon, une chemise...
Autre solution moins onéreuse :
Se balader avec une veste normale, voire pas de veste du tout puisque les beaux jours semblent revenir.
Inconvénient : le geek ne peut plus trimballer tous ses gadgets.
Avantage : le geek récupère une chance de rencontrer une femme.
"Let" permet d'une manière générale d'ordonner l'affectation d'une variable dans tous les cas où la forme raccourcie est ambigüe.
En principe, le shell développe les variables et procède à leur affection pendant la même étape, avant évaluation de l'expression ainsi formée. "let" permet ici la réinterprétation d'une expression déjà construite.
Dans le cas présent, ça permet par exemple de passer le nom de la variable à affecter dans les paramètres d'un script.
A priori, /etc/profile est toujours interprété lorsque bash est lancé en mode interactif. Une exception est peut-être faite pour le compte root, ce qui aurait du sens ...
Première chose : es-tu sûr que la console du runlevel 1 lance bien ton shell habituel et pas une version minimaliste ?
Cet exemple n'est pas probant. Je ne trouve pas inconcevable que le fait d'ouvrir un outil qui requiert les droits "root" et donc, te demande une première fois ton mot de passe via gksudo, permette ensuite, dans le délai imparti par sudo, d'en ouvrir une autre qui les requiert également, sans te demander à nouveau le mot de passe. La session X11 est vue comme un seul et même tty. Dans une console, ce comportement est strictement le même. Le délai de grâce de sudo permet justement de taper systématiquement le mot de passe quand on tape plusieurs commandes.
Justement, cette facilité se justifie en ligne de commande car l'utilisateur précise explicitement sudo à chaque fois mais surtout parce que l'administration en ligne de commande consiste généralement en une floppée de commandes successives, toutes éphémères.
S'il fallait que je saisisse mon mot de passe à chaque fois que j'utilise un outil graphique lié à l'administration dans un délai inférieur à 5 minutes, ce serait très lourd et on tomberait dans le second cas que tu décries comme "Mauvais".
C'est là que nos opinions diffèrent. Toutes ces applications sont persistantes, elles effectuent en général toutes les opérations demandées en une fois à la validation, et peuvent être beaucoup facilement lancées en parallèle par l'utilisateur de base. Étant donné qu'en outre, cela ne concerne qu'au plus une quinzaine d'applications, un délai de grâce ne se justifie absolument pas dans ce genre d'environnement.
D'autre part - et c'est son intérêt principal - un clicodrôme propose des options à l'utilisateur à l'inverse d'une ligne de commande à laquelle on doit les passer explicitement (et sans se tromper dans l'orthographe). Si l'on tient compte en plus de fait que bon nombre de foyers (auxquels Ubuntu se destine) utilisent un compte familial, il devient très simple de lancer une application censée être privilégiée comme n'importe quelle autre application du menu.
Il faut donc que :
- le processus ne soit pas rattaché à une console ;
C'est automatiquement le cas de toutes les applications lancées à partir du bureau graphique et non d'une ligne de commande. Et sans cela, il suffit à un processus de faire un setsid() ou un ioctl() avec TIOCNOTTY pour se détacher de sa console.
- l'uid du processus fasse partie du groupe admin ;
C'est forcément le cas aussi puisque tous les programmes sont lancés sous ton identité.
- que le mot de passe d'un utilisateur du groupe ait été tapé il y a moins de 5 minutes auparavant.
Cela fait quand même pas mal de conditions à retenir.
Non, il suffit de se mettre en attente et de surveiller l'exécution de gksudo, puis de voir si le même PID sous la même identité (root) correspond à un autre exécutable (suite d'un execve) pour savoir qu'un sudo a réussi et donc que le timestamp est valide pour 5 minutes. Si tu balances la commande à ce moment-là, elle sera toujours associée dans le log avec la précédente. Si tant est, bien sûr, que l'utilisateur lamdba lise le log.
En créant plaçant un sgid sur l'ensemble du système de fichier ?
Encore une drôle d'idée ...
sur l'exécutable d'aptitude ? Mais dans ce cas, si le compte de l'utilisateur est compromis, plus besoin de se farcir les failles locales pour escalader les privilèges...
Non, car au moins, seule cette commande pourra être exécutée ! Ça fait quand même toute la différence !
Un sudo même sans délai de grâce permet par défaut de lancer n'importe quelle commande !
Réduire le champ d'action obligatoire de root ne fera pas disparaître la menace d'intégrité du système pour autant.
Encore une fois, il ne faut pas confondre l'utilisation de sudo et le passage vers root. Dans le cas du serveur FTP, tout l'administration peut être faite sous l'identité d'un pseudo-user, et c'est l'identité de celui-ci qu'il faut prendre, pas celle de root.
Il est important de remarquer que, d'une part, le fichier /etc/sudoers permet de spécifier une liste de commande explicitement autorisées, et également de choisir une identité autre que root.
Il est de fait qu'Ubuntu n'exploite pas du tout ces possibilités, pas plus que la plupart des distributions. Le premier utilisateur fraîchement déclaré a donc la possibilité de passer root et de faire n'importe quoi, même lorsqu'il débute sur le système. Et c'est pour moi une grave faille de sécurité.
Là où j'attends un peu plus que des « on-devrait-faire-comme-ça », c'est par rapport à X.org, sujet technique que je maîtrise mal en profondeur. Démonstration de ce que tu avances (c'est sans doute vrai)
Si tu parles du délai de grâce, c'est facile à vérifier. sudo flanque ses timestamps dans /var/run/sudo/loginduuser (problablement avec un touch ou assimilé). Il y crée une entrée qui porte le nom du tty depuis lequel la commande a été lancée, pour que ce délai n'affecte que la console de travail de l'utilisateur et pas une autre. Si tu lances l'affaire depuis X-Window (mais pas depuis un Xterm, rattaché, lui, à un /dev/pts/*), il n'y a pas de console et le timestamp s'applique sur unknown. Moralité : tous les processus qui ne sont pas ou plus rattachés à une console peuvent en profiter.
Si tu veux faire le test, colle l'applet de lancement d'applis en ligne de commande dans ton tableau de bord Gnome, ouvre une des applications du menu Administration d'Ubuntu avec ton mot de passe habituel, puis lance gksudo depuis l'applet avec la commande de ton choix.
et que préconises-tu pour y pallier ?
Configurer gksudo via le fichier /etc/sudoers pour qu'il n'accorde pas de délai de grâce aux processus sans tty. Autant ça se justifie parfaitement en ligne de commande quand on fait de l'administration, autant le recours aux applis du menu d'administration est occasionnel et ne justifie pas une telle facilité, surtout si c'est à l'insu de l'utilisateur.
Ce que je préconise surtout, c'est une vraie réflexion sur le sujet, et c'est ce que l'on a commencé à faire dans les discussions indiquées :
- Ouvrir une session root pour tout faire = Mauvais;
- Taper son mot de passe à tout bout de champ = Mauvais.
Je pense qu'il faut donc recourir le moins souvent à root et faire en sorte que la plupart des opérations soient réversibles.
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.
Tu préfères que l'utilisateur se connecte tout le temps en root ou dispose d'un terminal root en permanence ?
Honnêtement, c'est quand même une drôle d'idée ...
Ce qui est inquiétant, c'est que le fait même que tu considères cette option comme seule solution de substitution, ça laisse quand même songeur. Il n'y pas que root sous Unix ... C'est de cette manière que l'on arrive à des horreurs de ce style :
En l'occurence, que Ubuntu s'appuie sur sudo plutôt que sur un truc à eux pour gagner des privilèges, c'est plutôt une bonne chose. Par contre, avoir à switcher systématiquement vers root chaque fois que l'on ouvre quelque chose dans le menu d'administration sous X-Window, ça me pose problème pour trois raisons :
1) L'utilisateur prend l'habitude de saisir son mot de passe pour un oui ou pour un non, et ça devient dangereux.
2) Il suffit de mettre un client graphique à l'écoute des événements pour intercepter ce mot de passe !
3) Au contraire de la majorité des outils en ligne de commande qui effectuent immédiatement l'opération demandée et ressortent, une application X (et GNOME à plus forte raison encore), est persistante dans l'environnement, et accapare et influe sur de nombreuses ressources connexes.
T'inquiète, pour la majorité des forums, tu écris encore trop bien. Pour la plupart des gens, ce niveau de français est devenu la norme (et de là à ce qu'elle soit avalidée par l'ISO en fast-track, il n'y a qu'un pas, à mon avis ...).
[^] # Re: Non ...
Posté par Obsidian . En réponse au journal Cérémonie de démarrage de Windows 98. Évalué à 3.
[^] # Re: ...
Posté par Obsidian . En réponse au journal [HS] "L'enseignement catholique fait le plein". Évalué à 7.
Quand j'étais au lycée, j'avais un prof' principal qui, lui, visait 100% de réussite au bac, ce qui nous faisait doucement sourire. On a beaucoup moins rigolé quand on s'est rendu compte qu'il s'arrangeait pour éjecter au cours de l'année les élèves qui, selon lui, n'aurait apparement pas le niveau au jour J. Pour le reste, j'ai eu la même année des enseignants formidables qui, outre la qualité de leurs cours, ont été les premiers à sonner l'alarme quand j'ai commencé à être très en difficulté.
Bref, être professeur, plus que n'importe quel autre métier, se doit d'être une vocation. Malheureusement, comme dans toute filière, on aura des carriéristes qui porteront préjudice à leurs élèves.
C'est pour cela que je refuse de jeter l'anathème sur le système scolaire en général, même s'il m'a beaucoup déçu à certaines époques. Ensiegner n'est pas facile et, même dans la plus pourrie des écoles de quartier, il y a toujours un enseignant qui fait son travail avec beaucoup de conscience et qu'il faut soutenir.
Vouloir le meilleur pour ses enfants est parfaitement normal et j'en ferais autant, mais le problème de " l'attitude consumériste ", selon moi, c'est que l'on sait très bien que de cette manière, il n'y aura pas de place pour tout le monde. Faire jouer la concurrence n'est valable que si toutes les écoles deviennent privées, et ce n'est pas souhaitable. Même les familles les plus aisées devraient avoir le droit à un enseignement public de qualité, au même titre que tous les autres.
Le vrai problème est de pouvoir s'impliquer dans la vie de l'école, en tant qu'élève ou en tant que parent d'élève, pour pouvoir y faire changer les choses quant elles ont réellement besoin de l'être. Et notamment, trouver des financements.
Je n'ai rien contre le fait de "pousser les murs" des écoles privées en soi, si ce n'est que cela risque de conduire à la fermeture de plus de classes et d'écoles, avec des gamins obligés de faire 40 kms par jour par rallier la plus proche. Et tout cela sans garantie que les programmes privés tiennent leurs promesses.
# MS ? Linux ?
Posté par Obsidian . En réponse au message Y a t'il un Home Server Linux. Évalué à 2.
Peu importe, MultiDeskOS était largement en avance sur tout le monde !
[^] # Re: perl::tk
Posté par Obsidian . En réponse au message menu interactif. Évalué à 2.
Si tu as utilisé les fonctions d'une bibliothèque en C, il faut retrouver une bibliothèque équivalente en Perl.
Si tu as utilisé les séquences CSI avec Escape, il suffit de rebalancer les mêmes à l'écran puisque c'est le terminal qui gère sa surbrillance, pas directement le programme en lui-même ...
[^] # Re: Publions des documents ODF
Posté par Obsidian . En réponse à la dépêche OpenXML recalé par l'ISO. Évalué à 3.
[^] # Re: ls
Posté par Obsidian . En réponse au message Connaître le MAJOR et le MINOR d'un fichier périphérique. Évalué à 3.
[^] # Re: Voc
Posté par Obsidian . En réponse au journal clé d'identification d'un utilisateur?. Évalué à 3.
Personnellement, je commence à me méfier des dictionnaires. Ils sont tenus comme étant la référence absolue et indiscutée de ce qui est valable ou non en français, alors que personne ne sait réellement qui les définit.
Ce qui m'ennuie particulièrement, c'est qu'il s'agit en général des mêmes personnes qui, sous prétexte de parler une langue "vivante", en profitent pour y ajouter n'importe quoi. C'est dans le même esprit que les effets de mode temporaires et surtout anglicismes mal traduits propre à un jargon particulier (spécialement vrai en informatique) se retrouvent édités dans un souci d'exhaustivité, simplement pour être plus efficace que le concurrent.
A la limite, je n'ai rien contre çà tant que cela s'en tient à la fonction première du dictionnaire : définir un mot dont on ignore le sens. Par contre, je pense qu'il est vital de repérer ces mots comme néologismes, jargon et autre et de bien préciser qu'ils ne doivent pas, à priori, être utilisés dans le langage courant.
Allez hop, troll relecture relancé.
[^] # Re: Voc
Posté par Obsidian . En réponse au journal clé d'identification d'un utilisateur?. Évalué à 1.
[^] # Re: Mandrake
Posté par Obsidian . En réponse au journal Quelle distrib a failli vous faire lâcher Linux (journal suicide inside).... Évalué à 3.
Par défaut, un bon système devrait être blindé contre les erreurs de débutants. Après, si le gars fait des conneries en sudo, ben ça le regarde ... pour autant qu'il ne soit pas systématiquement obligé de passer par là pour effectuer des tâches d'administration régulières !
[^] # Re: Comme en C
Posté par Obsidian . En réponse au message opérations sur les bits << et >>. Évalué à 2.
C'est curieux quand même. C'est toujours une très bonne chose de demander mais, en l'occurence, le plus simple, c'était encore d'essayer, n'est-ce-pas ?
[^] # Re: Diantre !
Posté par Obsidian . En réponse au journal OpenOffice.org et Mac ? Une "méchante" critique :(. Évalué à 7.
[^] # Re: c'est toi qui voit
Posté par Obsidian . En réponse au journal PC-NET, fin ?. Évalué à 1.
C'est idéal quand on habite dans un petit appartement par exemple. En plus, comme on peut le trimballer partout, on évite en général d'avoir à synchroniser ses machines. Le seul inconvénient, c'est qu'ils sont très peu évolutifs, et que l'on ne peut pas y mettre une carte 3D à refroidissement par eau :-) Dans le premier cas de figure, j'ai tendance à dire que cela ne pénalise ni ceux qui changent fréquemment de config', ni ceux qui gardent la même pendant 10 ans.
La seule chose que je recommande, c'est la possibilté de le docker dans une station d'accueil.
Donc le choix n'est pas évident du tout.
# Option numéro 2
Posté par Obsidian . En réponse au journal Comment surprendre agréablement votre femme ?. Évalué à 5.
Autre solution moins onéreuse :
Se balader avec une veste normale, voire pas de veste du tout puisque les beaux jours semblent revenir.
Inconvénient : le geek ne peut plus trimballer tous ses gadgets.
Avantage : le geek récupère une chance de rencontrer une femme.
[^] # Re: Dur dur l'utilisation de Vista
Posté par Obsidian . En réponse au journal L'ex directeur marketing de Microsoft France analyse Vista. Évalué à 1.
[^] # Re: pour les subsitutions ?
Posté par Obsidian . En réponse au message BASH : fonction 'let'. Évalué à 3.
En principe, le shell développe les variables et procède à leur affection pendant la même étape, avant évaluation de l'expression ainsi formée. "let" permet ici la réinterprétation d'une expression déjà construite.
Dans le cas présent, ça permet par exemple de passer le nom de la variable à affecter dans les paramètres d'un script.
# Shell, etc.
Posté par Obsidian . En réponse au message /etc/profile non pris en compte ?. Évalué à 2.
Première chose : es-tu sûr que la console du runlevel 1 lance bien ton shell habituel et pas une version minimaliste ?
[^] # Re: Belle faute...
Posté par Obsidian . En réponse au journal Debian sapumemesisailibre sai Linux qui le dit. Évalué à 4.
[^] # Re: Parc linux non homogéne
Posté par Obsidian . En réponse à la dépêche Les virus sous Linux. Évalué à 2.
Justement, cette facilité se justifie en ligne de commande car l'utilisateur précise explicitement sudo à chaque fois mais surtout parce que l'administration en ligne de commande consiste généralement en une floppée de commandes successives, toutes éphémères.
C'est là que nos opinions diffèrent. Toutes ces applications sont persistantes, elles effectuent en général toutes les opérations demandées en une fois à la validation, et peuvent être beaucoup facilement lancées en parallèle par l'utilisateur de base. Étant donné qu'en outre, cela ne concerne qu'au plus une quinzaine d'applications, un délai de grâce ne se justifie absolument pas dans ce genre d'environnement.
D'autre part - et c'est son intérêt principal - un clicodrôme propose des options à l'utilisateur à l'inverse d'une ligne de commande à laquelle on doit les passer explicitement (et sans se tromper dans l'orthographe). Si l'on tient compte en plus de fait que bon nombre de foyers (auxquels Ubuntu se destine) utilisent un compte familial, il devient très simple de lancer une application censée être privilégiée comme n'importe quelle autre application du menu.
C'est automatiquement le cas de toutes les applications lancées à partir du bureau graphique et non d'une ligne de commande. Et sans cela, il suffit à un processus de faire un setsid() ou un ioctl() avec TIOCNOTTY pour se détacher de sa console.
C'est forcément le cas aussi puisque tous les programmes sont lancés sous ton identité.
Non, il suffit de se mettre en attente et de surveiller l'exécution de gksudo, puis de voir si le même PID sous la même identité (root) correspond à un autre exécutable (suite d'un execve) pour savoir qu'un sudo a réussi et donc que le timestamp est valide pour 5 minutes. Si tu balances la commande à ce moment-là, elle sera toujours associée dans le log avec la précédente. Si tant est, bien sûr, que l'utilisateur lamdba lise le log.
Encore une drôle d'idée ...
Non, car au moins, seule cette commande pourra être exécutée ! Ça fait quand même toute la différence !
Un sudo même sans délai de grâce permet par défaut de lancer n'importe quelle commande !
Encore une fois, il ne faut pas confondre l'utilisation de sudo et le passage vers root. Dans le cas du serveur FTP, tout l'administration peut être faite sous l'identité d'un pseudo-user, et c'est l'identité de celui-ci qu'il faut prendre, pas celle de root.
Il est important de remarquer que, d'une part, le fichier /etc/sudoers permet de spécifier une liste de commande explicitement autorisées, et également de choisir une identité autre que root.
Il est de fait qu'Ubuntu n'exploite pas du tout ces possibilités, pas plus que la plupart des distributions. Le premier utilisateur fraîchement déclaré a donc la possibilité de passer root et de faire n'importe quoi, même lorsqu'il débute sur le système. Et c'est pour moi une grave faille de sécurité.
[^] # Re: Parc linux non homogéne
Posté par Obsidian . En réponse à la dépêche Les virus sous Linux. Évalué à 3.
Si tu parles du délai de grâce, c'est facile à vérifier. sudo flanque ses timestamps dans /var/run/sudo/loginduuser (problablement avec un touch ou assimilé). Il y crée une entrée qui porte le nom du tty depuis lequel la commande a été lancée, pour que ce délai n'affecte que la console de travail de l'utilisateur et pas une autre. Si tu lances l'affaire depuis X-Window (mais pas depuis un Xterm, rattaché, lui, à un /dev/pts/*), il n'y a pas de console et le timestamp s'applique sur unknown. Moralité : tous les processus qui ne sont pas ou plus rattachés à une console peuvent en profiter.
Si tu veux faire le test, colle l'applet de lancement d'applis en ligne de commande dans ton tableau de bord Gnome, ouvre une des applications du menu Administration d'Ubuntu avec ton mot de passe habituel, puis lance gksudo depuis l'applet avec la commande de ton choix.
Configurer gksudo via le fichier /etc/sudoers pour qu'il n'accorde pas de délai de grâce aux processus sans tty. Autant ça se justifie parfaitement en ligne de commande quand on fait de l'administration, autant le recours aux applis du menu d'administration est occasionnel et ne justifie pas une telle facilité, surtout si c'est à l'insu de l'utilisateur.
Ce que je préconise surtout, c'est une vraie réflexion sur le sujet, et c'est ce que l'on a commencé à faire dans les discussions indiquées :
- Ouvrir une session root pour tout faire = Mauvais;
- Taper son mot de passe à tout bout de champ = Mauvais.
Je pense qu'il faut donc recourir le moins souvent à root et faire en sorte que la plupart des opérations soient réversibles.
[^] # 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.
[^] # Re: Parc linux non homogéne
Posté par Obsidian . En réponse à la dépêche Les virus sous Linux. Évalué à 4.
Honnêtement, c'est quand même une drôle d'idée ...
Ce qui est inquiétant, c'est que le fait même que tu considères cette option comme seule solution de substitution, ça laisse quand même songeur. Il n'y pas que root sous Unix ... C'est de cette manière que l'on arrive à des horreurs de ce style :
https://linuxfr.org/forums/15/22562.html
Concernant sudo, on a déjà eu l'occasion d'en discuter ici :
https://linuxfr.org/comments/801182.html#801182
https://linuxfr.org/comments/839682.html#839682
En l'occurence, que Ubuntu s'appuie sur sudo plutôt que sur un truc à eux pour gagner des privilèges, c'est plutôt une bonne chose. Par contre, avoir à switcher systématiquement vers root chaque fois que l'on ouvre quelque chose dans le menu d'administration sous X-Window, ça me pose problème pour trois raisons :
1) L'utilisateur prend l'habitude de saisir son mot de passe pour un oui ou pour un non, et ça devient dangereux.
2) Il suffit de mettre un client graphique à l'écoute des événements pour intercepter ce mot de passe !
3) Au contraire de la majorité des outils en ligne de commande qui effectuent immédiatement l'opération demandée et ressortent, une application X (et GNOME à plus forte raison encore), est persistante dans l'environnement, et accapare et influe sur de nombreuses ressources connexes.
[^] # Re: Parc linux non homogéne
Posté par Obsidian . En réponse à la dépêche Les virus sous Linux. Évalué à -4.
[^] # Re: question (bis)
Posté par Obsidian . En réponse au journal Installez Linux depuis Windows !. Évalué à 1.
[^] # Re: quelques explications s'il vous plait
Posté par Obsidian . En réponse à la dépêche Et la guerre des formats bureautique continue. Évalué à 2.
# Mouais ...
Posté par Obsidian . En réponse au message Fuzzing windows a partir de Linux. Évalué à 3.
... ça devrait déjà suffire à mettre le souk, je crois.