Décidément, c’est la fête à MacOS ces derniers temps. :heink:
Bien sûr, une intervention de l’utilisateur est toujours nécessaire, mais là, il y a quand même un problème critique qu’Aplle ferait bien de corriger promptement:
"If a script is given an extension such as "jpg" or "mov" and stored within a ZIP archive, Mac OS X will add a binary metadata file to the archive which determines its association. This metafile instructs the operating system on another Mac to open that file with the Terminal application – regardless of its extension or the symbol displayed in the Finder. The Terminal will redirect scripts without an interpreter line directly to bash, the standard shell in OS X."
Il y a effectivement un premier problème: Safari reconnait le fichier comme “sur” et l’execute.
Mais le problème ne vient pas que de Safari, qui ouvre les fichiers de confiance automatiquement, mais de la façon dont ces fichiers sont gérés par le système.
À chaque fichier sont potentiellement attachés des meta-donnés (l’icône si elle est spécifique, l’application à utiliser pour ouvrir le fichier
)
En effet, un simple fichier texte (éventuellement renommé en .jpeg et disposant d’une belle icône) pourra s’executer via le terminal car le fichier en question est reconnu comme executable, alors qu’il n’est pas sensé l’être.
Il y a déjà des solutions de contournement (désactiver l’ouverture automatique des fichiers “sûrs” dans Safari, renommer le terminal en TerminEl.app par exemple…) mais aucune qui soit vraiment satisfaisante en attendant qu’Apple corrige ce problème: un fichier texte qui ne contient pas #!/bin/csh (ou equivalent) en entête ne devrait pas pouvoir s’executer directement dans le terminal sans l’intervention de l’utilisateur.
ah ouais, ça devient du lourd quand même. A propos de la fonction de Safari mise en cause, celle ci avait déjà été pointée du doigt lors de la “faille” des widgets de Tiger (non exploitée heureusement). Apple ferait mieux de commencer à s’attaquer à cette fonction (la virer :ane:) avant de colmater ce que tu décris ici.
Pour une fois je ne suis que partiellement d’accord avec toi.
Le fait d’executer n’importe quel fichier avec n’importe quelle application et que ceci ne soit valable que pour ce fichier est vraiment une fantastique possibilité que j’utilise très souvent. Je ne vois effectivement pas pourquoi le système se baserait sur l’extension ; c’est un procédé archaique que j’ai toujours détesté…
Le problème principal est simplement que le zip contenant le faux jpg est considéré comme sur par safari.
> Le fait d’executer n’importe quel fichier avec n’importe quelle application et que ceci ne soit valable que pour ce fichier est vraiment une fantastique possibilité que j’utilise très souvent.
Tou à fait.
> Je ne vois effectivement pas pourquoi le système se baserait sur l’extension ; c’est un procédé archaique que j’ai toujours détesté…
J’ai jamas dit ça. Les extensions, c’est nul.
> Le problème principal est simplement que le zip contenant le faux jpg est considéré comme sur par safari.
Non, le problème est que le terminal tente d’executer un fichier texte tout à fait normal.
Safari a raison d’ouvrir le fichier (que ce soit un jpg ou un texte) mais le terminal a tord de vouloir interpréter les commandes du fichier texte.
Je m’étais arreté trop tôt dans mon résonnement et j’ai effectivement tort :jap:
Je pensais que le “#!/bin/csh” n’avait aucune importance car dans les 2 cas (avec et sens) le script etait bien executé mais, en ajoutant “#!/bin/csh”, le script est bien vu comme un executable et n’est pas executer automatiquement.
Le principal problème vient donc de la console qui autorise l’execution d’un script “mal formaté”.
J’ai pas bien compris les tenants et les aboutissants :ane:
En gros :
On a un script shell mal formé (il manque le shebang) renommé en .jpg. Safari lit les metadonnées et voit que c’est un script (mais ne detecte pas la malformation), donc le lance avec l’appli associée (le Terminal) et là c’est le drame.
Nan ?
Auquel cas la faute est plutôt au terminal qui ne devrait pas lancer de script sans shebang (à moins de le lancer avec “sh /chemin/du/script.jpg” mais c’est pas le cas là) ?
Mmmh merci pour les précisions, mais alors, pourquoi Safari passe-t-il le texte au Terminal et pas au bloc-note ? Il y a un flag executable sur le fichier qui se conserve par le protocole de transfert utilisé ?