Installer bash 4.3.27

poco

Membre actif
14 Décembre 2007
424
11
Mi-curiisité, mi-paranoia j'ai essayé d'installer ma derniére version de bash sur mon MBA en 10.8.5 à partir de a page de "www.amsys.co.uk/2014/blog/shellshock-bug-workaround/#.VChurd7Eg72"

J'ai apparemment bien installé la version 4.3.27 :

Warning: bash-4.3.27 already installed


mais quand je fais un :

bash --version

j'obtiens :

GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin12)
Copyright (C) 2007 Free Software Foundation, Inc.

Qui croire? :p
 
Tu l'as peut-être installée mais :
a) elle n'est peut-être (ou sans doute ?) pas dans le chemin des exécutables (variable d'environnement PATH) ; ou alors pas en premier dans ce même chemin
b) même si la variable PATH a été configurée comme il faut, le shell lancé pour un utilisateur est indiqué absolument (c'est-à-dire avec son chemin complet) ; pour utiliser un autre shell, il faut (et il suffit) d'aller dans la définition du compte (au rayon avancé) et d'indiquer le chemin complet du shell souhaité.
 
Tu l'as peut-être installée mais :
a) elle n'est peut-être (ou sans doute ?) pas dans le chemin des exécutables (variable d'environnement PATH) ; ou alors pas en premier dans ce même chemin
b) même si la variable PATH a été configurée comme il faut, le shell lancé pour un utilisateur est indiqué absolument (c'est-à-dire avec son chemin complet) ; pour utiliser un autre shell, il faut (et il suffit) d'aller dans la définition du compte (au rayon avancé) et d'indiquer le chemin complet du shell souhaité.

Tu as certainement raison, mais là (hélas) s'arrête mes connaissances dans le Terminal.

Comment puis-je éditer la variable d'environnement PATH afin de lui indiquer le chemin du Bash V4 (et quel chemin?)

Merci
 
Salut poco.

Le Bourne shell natif : bash est par défaut dans «Mavericks» à l'adresse : /bin/bash où il cotoie les autres shells disponibles comme : csh, ksh etc. La version majorée 4.3.27 de bash que tu as installée je suppose par la commande dans le «Terminal» :

Bloc de code:
brew install bash

(qui implique, bien entendu, que le programme d'installation HomeBrew soit préalablement installé dans l'OS pour pouvoir être honorée) se retrouve, par contre, à l'adresse cryptique : /usr/local/Cellar/bash/4.3.27/bin/bash où ce programme est comme un paquet qui stagnerait en l'état sans ustensilité (vérifie si tu as bien l'objet en question à l'adresse indiquée).

[il peut se faire que le programme brew ne soit pas à jour chez ceux qui l'ont installé naguère et laissé s'empoussiérer, auquel cas il n'installera pas la dernière version de bash --> avant de passer la commande brew install bash, passer d'abord -->

Bloc de code:
brew update

et faire preuve d'un peu de patience pour que la màj s'installe...]

Si tu veux par suite, lorsque tu lances le «Terminal», être automatiquement dans le Bourne Shell : bash_4.3.27, à mon avis le procédé absolument le plus simple est de renommer d'une part le programme bash à l'adresse /bin/bash en lui ajoutant le suffixe courant des programmes acutellement mis sur la touche : ~orig pour donner --> /bin/bash~orig ; et d'autre part de créer une copie sans changement d'intitulé du programme : /usr/local/Cellar/bash/4.3.27/bin/bash à l'adresse : /bin/bash - ce qui fait que tous les paramètres (d'utilisateur etc.) qui pointaient en chemin absolu à /bin/bash antérieurement, inchangés en eux-mêmes, vont désormais pointer sur le programme : bash_4.3.27 renommé bash et localisé à l'emplacement attendu, et non plus sur l'ancien Bourne Shell déporté à son voisinage sous l'intitulé ségrégatif : bash~orig.

Pour ce faire, il te suffit dans le «Terminal» de passer les 2 commandes suivantes :

Bloc de code:
sudo mv /bin/bash /bin/bash~orig

et ↩︎ (presse la touche 'Entrée' du clavier pour activer la commande) --> une demande de password s'affiche (commande sudo) --> tape ton mot-de-passe admin à l'aveugle - aucun caractère ne se montrant à la frappe - et derechef ↩︎ --> le fichier bash vient d'être renommé bash~orig dans le répertoire /bin. À présent, tu enchaînes par :

Bloc de code:
sudo cp /usr/local/Cellar/bash/4.3.27/bin/bash /bin/bash

et ↩︎ (pas besoin de te ré-authentifier admin dans un délai de grâce de 5' par défaut où tu as le statut de sudoer) --> le programme /usr/local/Cellar/bash/4.3.27/bin/bash vient d'être copié dans le répertoire /bin sous l'intitulé de l'ancien Bourne Shell = bash --> c'est donc désormais par défaut ton shell d'accès quand tu lances le «Terminal» (pour autant que le chemin absolu du Shell d'accès --> /bin/bash n'ait pas été édité dans ta base de données d'utilisateur).

Si jamais tu souhaitais te raviser, un simple :

Bloc de code:
sudo rm /bin/bash

supprimerait cette copie dans le répertoire /bin de la version 4.3.27 et un simple :

Bloc de code:
sudo mv /bin/bash~orig /bin/bash

rétablirait l'ancien Bourne Shell à son intitulé primitif, en en re-faisant da capo le shell d'accès de l'utilisateur.

☞ testé par moi-même sans aucun problème sous «Mavericks 10.9.5», de l'install par brew via la substitution du programme bash dans /bin jusqu'au lancement du «Terminal» en version 4.3.27 du shell : bash - confirmation par la demande d'info : bash --version donnant en réponse :

Bloc de code:
GNU bash, version 4.3.27(1)-release (x86_64-apple-darwin13.4.0)
Copyright (C) 2013 Free Software Foundation, Inc.
Licence GPLv3+ : GNU GPL version 3 ou ultérieure <http://gnu.org/licenses/gpl.html>

et si je passe maintenant la commande :

Bloc de code:
env x='() { :;}; echo vulnerable' bash -c 'echo hello'

au lieu d'obtenir en réponse :

Bloc de code:
vulnerable

comme avant, j'obtiens un :

Bloc de code:
hello

censé me rendre 'hilare' alors que je m'en tamponne le coqullard :D


[Note: cette méthode triviale par 'substitution de l'objet' et 'préservation des paramètres de référence' évite la méthode formelle plus complexe d'édition des paramètres en vue de la désignation d'un nouvel objet de référence.]
 
Dernière édition par un modérateur:
Génial, mais je dois avoir merdé quelque part car au final sur le :

bash --version

J'obtiens :

dyld: Library not loaded: @@HOMEBREW_PREFIX@@/opt/readline/lib/libreadline.6.dylib
Referenced from: /bin/bash
Reason: image not found
Trace/BPT trap: 5


Pourtant la Commande :

brew install bash

Renvoie :

Warning: No developer tools installed.
You should install the Command Line Tools.
The standalone package can be obtained from
https://developer.apple.com/downloads
or it can be installed via Xcode's preferences.
Warning: bash-4.3.27 already installed


Je ne comprends pas car il me dit (aujourd'hui) qu'il manque les dev tools mais il me dit que le Bash 4.3.27 est déjà installé (par quel miracle j'ai réussi hier?)

Désolé, j'suis une bille en la matière.
 
Tu as dû installer un paquetage pré-compilé.
Le problème, avec brew est que ça compile à la volée, donc a besoin des outils de développement élémentaires (compilateurs et tout ça). Pas besoin de XCode, donc.

Une astuce prise dans OSX Daily : tape
Bloc de code:
xcode-select --install
ça demandera d'installer les outils de développement. Tu cliques sur le bouton Install et zou!
Ne choisis pas XCode si télécharger et installer des GB inutiles ne te tente pas...
 
Bon ben gagné!!!
Impossible de me logger sur mon compte. Je saisi le login et le mot de passe et le MBA tourne indéfiniment!!!
Au secours!
 
La presse annonce ce mardi une mise à jour d'Apple concernant ce problème, mais aucune mise à jour dans mon cas n'est disponible (ML). Et pour vous?

Présente sur le site d’Apple mais pas dans Mise à jour de logiciels. Une version pour chaque OS X : Lion, Mountain Lion et Mavericks.
 
Bon ben gagné!!!
Impossible de me logger sur mon compte. Je saisi le login et le mot de passe et le MBA tourne indéfiniment!!!
Au secours!

&#9757;&#65038;:D Je ne devrais pas me marrer, mais c'est plus fort que moi...

&#9828;


Bon : je viens de faire le test avec mon «Mavericks 10.9.5» --> j'ai mis à la corbeille le fichier /bin/bash (qui est donc la version 4.3.27 renommée) de sorte qu'il ne reste plus dans le répertoire /bin que l'ancien fichier bash actuellement renommé bash~orig. Cela fait, j'ai re-démarré mon Mac, et effectivement la sanction ne se fait pas attendre : après le logo &#63743; du Boot_Loader : boot.efi, la roue crantée giratoire du kernel entame une rotation indéfinie.

&#9758; Interprétation : en l'absence d'un fichier intitulé strictement bash dans le répertoire /bin, le kernel ne peut compléter sa tâche de chargement des infra-structures d'OSX. Application à ton cas, poco : tu as sûrement passé la commande dans le «Terminal» :

Bloc de code:
sudo mv /bin/bash /bin/bash~orig

et elle a marché en renommant le fichier bash y recelé, mais quand tu as passé l'autre commande :

Bloc de code:
sudo cp /usr/local/Cellar/bash/4.3.27/bin/bash /bin/bash

à mon avis elle a foiré, parce que brew, en l'absence des Command Line Developer Tools, n'avait pas réussi à faire une installation complète de bash - vraisemblablement le dossier bash sous-dossier 4.3.27, sub-dossier bin dans Cellar, mais dans ce dernier bin aucun 'objet terminal' comme un programme bash --> ta commande n'a rien copié du tout à l'adresse /bin en guise de shell du nom de bash [Je t'avais avisé d'aller vérifier dans /usr/local/Cellar/bash/4.3.27/bin/bash qu'il y avait bien l'objet attendu bash].

&#9831;​


Eh bien! Il m'a fallu environ 2' pour m'en sortir : j'ai re-démarré sur la Recovery HD, lancé le «Terminal» et saisi :

Bloc de code:
mv /Volumes/"Macintosh HD"/bin/bash~orig /Volumes/"Macintosh HD"/bin/bash

par quoi j'ai renommé le fichier primitif ré-intitulé bash~orig à son intitulé initial attendu dans /bin = bash. Puis j'ai re-démarré et le kernel n'a plus fait de difficulté, de sorte que j'ai pu ré-ouvrir ma session.

&#9825;


Donc poco, avant de tout ré-installer (par l'option Ré-installer OSX de la Recovery HD), démarre sur ta partition de récupération : soit par &#8984;R directement, soit en appuyant la touche &#8997; ('alt') au démarrage et en choisissant à l'écran de choix du disque de démarrage le disque : Récupération 10.9.x. Arrivé dans l'environnement du Bureau Simplifié de la Recovery, va à la barre de menus supérieure de l'écran, menu : Utilitaires et lance le «Terminal».

  • Commence par saisir la commande informative :

    Bloc de code:
    ls /Volumes

    et &#8617;&#65038; (appuie sur 'Entrée' pour activer la commande) --> tu vois la liste des volumes montés attachés à ton Mac, ce qui te donne l'intitulé exact de celui de ton OS que tu vas devoir ressaisir exactement. Si l'intitulé est en 2 mots séparés par un espace vide, comme le nom par défaut : Macintosh HD, alors tu l'écriras entre "" ainsi : "Macintosh HD" afin qu'il soit lu comme nom d'un objet unique. Tu remplaces dans ce qui suit mon "Macintosh HD" pris en exemple par l'intitulé exact de ton OS à la place requise dans la commande.

  • Enchaîne par la commande purement informative encore :

    Bloc de code:
    ls /Volumes/[COLOR="Red"]"Macintosh HD"[/COLOR]/bin

    et --> tu obtiens la liste des programmes exécutables du répertoire /bin, où tu vérifies la présence et l'intitulé exact du fichier bash renommé (j'ai eu la surprise de voir, pour ma part, que mon intitulé bash~orig (avec un tilde de liaison) était modifié en bash_orig (avec un tiret subalterne), et qu'il me fallait donc saisir ce dernier intitulé pour me faire comprendre...].

  • Il ne te reste plus qu'à passer la commande opératoire (attention aux espaces critiques!) :

    Bloc de code:
    mv /Volumes/[COLOR="Red"]"Macintosh HD"[/COLOR]/bin/[COLOR="DarkOrange"]bash[COLOR="Red"]~[/COLOR]orig[/COLOR] /Volumes/[COLOR="Red"]"Macintosh HD"[/COLOR]/bin/[COLOR="RoyalBlue"]bash[/COLOR]

    ou la commande :

    Bloc de code:
    mv /Volumes/[COLOR="Red"]"Macintosh HD"[/COLOR]/bin/[COLOR="DarkOrange"]bash[COLOR="Red"]_[/COLOR]orig[/COLOR] /Volumes/[COLOR="Red"]"Macintosh HD"[/COLOR]/bin/[COLOR="RoyalBlue"]bash[/COLOR]

    selon l'intitulé exact du fichier bashxxxxx dans le répertoire /bin (avec un tilde ~ ou avec un tiret subalterne _) et &#8617;&#65038;.

&#9758; Il ne te reste plus qu'à re-démarrer. DONE. Je te conseille d'appliquer la MÀJ signalée par Moonwalker dans son lien :D

&#9826;
 
Dernière édition par un modérateur:
Alors finalement j'ai fait une install de l'OS à partir de la partition de "recovery" et de Time Machine que j'avais eu la bonne idée de lancer hier matin…

J'en ai chi...é mais c'est bien fait pour moi. Vous pouvez vous moquer, je l'ai bien mérité. Je ne sais pas ce qui m'a pris, un moment de blues, 10 doigts qui s'ennuyaient…

Bref, je tiens à vous remercier de votre aide. Vous êtes TOP!!!

J'espére au moins que ma mésaventure servira de leçon à d'autres apprentis sorciers ;-)
 
Cher poco,

... c'est bien fait pour moi. Vous pouvez vous moquer, je l'ai bien mérité. Je ne sais pas ce qui m'a pris, un moment de blues, 10 doigts qui s'ennuyaient&#8230;

J'espére au moins que ma mésaventure servira de leçon à d'autres apprentis sorciers ;-)

&#9757;&#65038;:up: Ne crois pas que mon rire t'était adressé comme si tu eusses été un 'tout-autre' que moi - c'est bien plutôt parce que je me suis tellement reconnu dans ton attitude, que je me suis 'marré' de ce moi-même dont tu incarnais si bien l'aventurisme issu de l'ennui que tout 'aille trop bien' : ce petit macomaniac sur sa Palourde des origines cherchant par tous les moyens à planter son OS 9 par dés&#339;uvrement et n'y réussissant que trop bien... :D C'est Arthur Schopenhauer qui fait ce diagnostic magnifique : «Les hommes oscillent constamment entre le Désir et l'Ennui», si bien que lorsqu'ils sont dans la phase d'atonie (qu'on assimilerait sans peine à la routine du 'bonheur' : quand tout marche si bien que l'esprit s'ennuie de cet état de choses au lieu d'en éprouver de l'euphorie) - ressurgit le Désir d'un 'Mieux' que ce 'Bien' qui ne va pas manquer d'engendrer toutes sortes d'ennuis au pluriel, comme si le 'générique de l'Ennui' suscitait l'envie d'aléas dans le 'casting'...


-----&#9828;


Ta mésaventure (heureusement close) a été accidentelle : le programme brew qui permet de compiler-installer toutes sortes de logiciels à la volée demande les ressources 'extra' des Command Line Developer Tools - qui sont un supplément d'Xcode qu'on peut domicilier dans son OS en l'absence de l'application maîtresse - afin d'exécuter convenablement sa tâche. Par conséquent, brew tout seul n'a pas accompli le service demandé (installer le binaire : bash_4.3.27) et tout a foiré à partir de là... <si tu refais appel à brew sans avoir installé lesdits Command Line Developer Tools, la même foirade va immanquablement se reproduire>

Que cela ne t'empêche pas d'utiliser le lien indiqué par Moonwalker :coucou: ou la variante fournie par PDD :coucou: afin de télécharger le &#9758;OS X bash Update 1.0 &#8211; OS X Mavericks&#9756; : il s'agit d'un .dmg qui recèle un paquet d'installation, lequel va majorer directement le fichier du shell bash de ton répertoire /bin (que ta ré-instalaltion a re-créé à la version 3 primitive) à la version 4.3.27 indemne de la faille de sécurité qui t'a alarmé. Tu ne risques rien ce coup-ci : il y aura bien à l'arrivée toujours un fichier bash dans /bin et le kernel au re-démarrage ne trouvera rien à redire :D.

-----&#9831;


Personnellement, j'ai appris quelque chose en reproduisant ta mésaventure sur mon Mac : n'avoir qu'un fichier intitulé bash~orig à un moment donné dans le répertoire /bin d'OSX a pour effet que le kernel dans ces conditions est incapable de compléter sa tâche de chargement des 'fondamentaux' de l'OS au démarrage afin de passer la main au processus launchd.

Comme je suis moi-même toujours affecté de l'aventurisme risible dont je me moquais [faut-il en induire que je m'ennuie de la trop bonne marche de «Mavericks»?] :D, je me suis livré ce matin à une autre expérience décomposée en 2 variantes sur ce pauvre répertoire /bin -->


  • Après avoir re-nommé da capo l'exécutable bash (version 4.3.27) bash~orig, j'ai créé à partir du «Terminal» un fichier vide bidon du même nom que le binaire initial, par la commande :

    Bloc de code:
    sudo touch /bin/bash

    • et dans une 1ère variante, j'ai rajouté à ce fichier doté automatiquement des permissions :

      Bloc de code:
      -rw-r--r-- root  wheel  /bin/bash

      l'executive_bit capable de le faire passer pour un fichier exécutable standard par la commande :

      Bloc de code:
      sudo chmod 555 /bin/bash

      qui l'a doté des permissions régulières :

      Bloc de code:
      -r-xr-xr-x root  wheel  /bin/bash

      et j'ai re-démarré --> le kernel n'a absolument rien trouvé à redire à mon leurre ('decoy'), mais a complété sa routine de chargement et a passé la main à launchd sans barguigner, si bien que j'ai pu ouvrir ma session sans coup férir. Évidemment, si je lance le «Terminal», comme mon chemin absolu d'utilisateur pointe, en guise de Shell d'accès, au fichier /bin/bash bidon, je n'ai aucun shell disponible me permettant de passer des commandes.

      ------------------------------------------------&#10057;

    • Après une petite manip me redotant d'un shell d'accès dans le «Terminal», j'ai rétro-gradé mon fichier 'leurre' /bin/bash au plan des permissions à sa situation initiale par la commande :

      Bloc de code:
      sudo chmod 644 /bin/bash

      qui élimine l'executive_bit pour tous les accédants au fichier en le ramenant à la situation première :

      Bloc de code:
      -rw-r--r-- root  wheel  /bin/bash

      et j'ai re-démarré --> la sanction ne se fait pas attendre : da capo, le kernel s'avère incapable de compléter sa tâche de chargement des fondamentaux d'OSX et ne passe donc jamais la main au processus launchd, d'où impossibilité d'ouvrir une session.

      Impavide, j'ai re-démarré sur la Recovery HD et dans son «Terminal» (fonctionnel, lui, car le volume de la partition de récupération embarque un Système OSX simplifié comportant un répertoire /bin dans lequel un exécutable bash est bien disponible comme Shell d'accès de l'utilisateur_avatar de root : -3.2), j'ai passé la commande humoristique :

      Bloc de code:
      chmod 555 /Volumes/"Macintosh HD"/bin/bash

      restituant l'executive_bit au fichier 'leurre' bash qui (je le rappelle) est un fichier vide portant décorativement le nom de bash et j'ai re-démarré --> le kernel n'y a vu que du feu, a passé la main à launchd à complétion de sa tâche de chargement et j'ai pu me re-loger dans ma session.

    &#10056;


&#9758; en apostille de ces 'tribulations' volontaires dont l'auteur revendique l'entière futilité en la soumettant, en juste retour des choses, au rire mérité de poco :D - j'ai appris quand même 2 petites choses que j'ignorais auparavant : le kernel d'OSX requiert absolument l'existence dans le répertoire /bin d'un fichier intitulé bash et le statut d'exécutable de ce fichier, c'est-à-dire une apparence de binaire au plan des permissions (= l'executable_bit : x) sans qu'aucune ligne de code n'ait à exister intrinsèquement dans ledit fichier. La condition nécessaire et suffisante pour le kernel est donc l'existence d'un objet porteur à la fois du nom de bash et de l'executable_bit : x dans le répertoire : /bin - quand bien même cet objet n'a que l'apparence et non la nature d'un fichier exécutable en terme de contenu d'écriture.

-----&#9825;
 
Dernière édition par un modérateur: