Dans Chrome OS, Bash n'exécutera pas mon script. Comment faire exécuter à Bash mon script?


16

J'ai un foo.shfichier dans mon répertoire actuel. Si j'essaye de courir ./foo.sh, j'obtiens:

-bash: ./foo.sh: /bin/sh: bad interpreter: Permission denied

Mais si je cours, /bin/sh ./foo.shça fonctionne bien.

Comment puis-je résoudre ce problème afin que je puisse simplement exécuter ./foo.sh et qu'il l'exécute automatiquement avec / bin / sh?

Edit: D'accord, c'est Chrome OS et ce dossier particulier est monté avec noexec. Apparemment, cela déjoue la capacité de simplement courir ./foo.sh; mais pourquoi? Pourquoi puis-je toujours courir sh foo.shpour atteindre exactement la même chose? Quelle sécurité noexecdonne alors?


1
la sécurité par l'obscurité
Michael Durrant

Avez-vous essayé si l'exécution de ". Foo.sh" fonctionne?
Daniele Testa

@DanieleTesta Cette question est une ancienne relique d'une époque lointaine. J'utilisais un Google Cr-48, l'un des premiers Chromebooks, exécutant une version assez précoce (mais stable) de ChromeOS. Nous avons parcouru un long chemin depuis et je ne pense pas que cette question s'appliquerait aux dernières versions de ChromeOS, mais je ne l'ai pas utilisé pour le dire avec certitude. Quoi qu'il en soit, je pense que votre variation aurait également fonctionné, mais il faut le tester avant de dire avec certitude. Je ne sais toujours pas exactement comment noexecfonctionne sa magie.
Ricket

Réponses:


22

L' noexecindicateur s'appliquera de manière appropriée aux scripts, car ce serait le comportement "attendu".

Cependant, le réglage noexecarrête uniquement les personnes qui ne savent pas suffisamment ce qu'elles font. Lorsque vous exécutez, vous exécutez sh foo.shréellement à shpartir de son emplacement par défaut (probablement /bin) qui ne se trouve pas sur un système de fichiers monté avec noexec.

Vous pouvez même vous déplacer noexecpour les fichiers binaires normaux en appelant lddirectement.

cp /bin/bash $HOME
/lib/ld-2.7.so $HOME/bash

Cela exécutera bash, qu'il soit ou non sur un système de fichiers monté avec noexec.


5
+1 pour mentionner ld.so(intelligent)
amphétamachine

J'ai essayé vos deux commandes; "impossible d'ouvrir le fichier d'objet partagé: aucun fichier ou répertoire de ce type" - en raison de la copie de sh mais de l'exécution de bash. Alors j'ai essayé /lib/ld-2.10.1.so $HOME/shet retourné une autre erreur lors du chargement des bibliothèques partagées: /home/chronos/user/sh: failed to map segment from shared object: Operation not permitted. Je ne sais pas si ce que vous avez dit était faux ou si quelque chose d'autre interfère. Par exemple, / est monté en lecture seule.
Ricket

Eh bien, je ne pourrais pas dire avec certitude parce que je n'ai pas de copie de ChromeOS pour essayer. Je suis assez confiant que cela peut fonctionner avec quelques modifications, mais sans pouvoir l'essayer moi-même, je ne sais pas ce que cela pourrait être.
bahamat le

Eh bien, j'aimerais penser que c'est parce que Chrome OS est correctement verrouillé. Cela semble être assez sûr, mais je suppose que nous verrons avec le temps!
Ricket

1
Il y a une différence entre ldet ld.so. ldest un éditeur de liens utilisé pour lier le code objet pour former un binaire lors de la compilation, tandis que ld.sol'éditeur de liens d'exécution exécute une action similaire lors de l'exécution d'un programme. L'éditeur de liens auquel il est fait référence ici est l'éditeur de liens au moment de l'exécution.
Kusalananda

5

Vous pouvez également obtenir cette erreur (ou un message très, très similaire) si vous essayez d'exécuter un fichier avec des fins de ligne MS-DOS de 2 octets (retour chariot).

Vim est si intelligent ces jours-ci qu'il ne vous montre pas nécessairement que le chariot retourne sous la forme «^ M». Ainsi, vous pouvez vous laisser berner si vous ne vérifiez pas ce que Vim pense du "format de fichier" et que vous vous appuyez uniquement sur l'apparence à l'écran.

Dans ce cas, le "#! / Bin / sh ^ M" amène le noyau à rechercher "/ bin / sh ^ M", ce qu'il ne peut pas. Mauvais interprète, en effet.


2

Si vous avez la possibilité d'exécuter le script ou le programme à partir d'une clé USB (ou d'un autre support amovible), vous pouvez essayer de le démonter et de le remonter manuellement:

  1. Branchez la clé USB

  2. Trouver un périphérique de clé USB avec $ mount

  3. Prenez-en note; supposons que c'est/dev/sdb1

  4. Démontez la clé USB:

    $ cd /media/removable
    
    $ sudo umount mountpoint

Enfin, remontez la clé USB:

$ sudo mount /dev/sdb1 mountpoint

Avec mountpoint, le nom de montage de la clé USB


1

Pour des raisons de sécurité du système sur ChromeOS / ChromiumOS, certains dossiers sont marqués noexecet vous devez soit remonter avec la commande ci-dessous, soit utiliser un chemin alternatif qui n'a pas été noexecdéfini, comme le deuxième exemple.

Ces commandes supposent que vous êtes au moins en mode développeur et que vous avez accès à shellwith chronos@localhost / $et pas seulement crosh>et que vous connaissez le mot de passe sudo.

sudo mount -i -o remount,exec /home/chronos/user/

La méthode la plus durable qui devrait survivre à une mise à niveau, car Google réserve la plupart des /usr/localdéveloppeurs:

sudo mkdir -p /usr/local/bin/ && sudo chown -R chronos: /usr/local/bin/
cp ${HOME}/Downloads/foo.sh /usr/local/bin/

L'avantage supplémentaire de mettre les choses ici est qu'elles se trouvent $PATHdéjà dans (essayez echo $PATHde le confirmer), vous n'avez donc pas besoin d'utiliser le chemin complet pour exécuter des scripts ou des binaires qui sont dedans /usr/local/binet qui ont été chmod +xexécutés dessus.


2
Salut, bienvenue sur l'Unix SE! Remarque, les réponses à commande unique ne sont pas considérées comme très HQ ici. Je suggère d'expliquer ce que vous faites et pourquoi.
peterh

0

J'avais la même question. Mon problème était avec la carte SD. Cela a fonctionné pour moi, et c'est beaucoup plus simple que les autres réponses ici. Je l'ai appris du numéro 928 de Crouton .

$ sudo mount -o remount,exec /media/removable/SD\ Card

Notez que vous devez utiliser le point de montage, pas le périphérique (/ dev / mmcblk1p1). Même chose pour USB (/ dev / sdb1) dans votre cas. Seul le point de montage est différent:

$ sudo mount -o remount,exec /media/removable/USB\ Drive

Vous saurez que cela a eu l'effet souhaité car "noexec" disparaîtra des options de montage lorsque vous interrogerez.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.