hello.app crasht, aber hello.exe nicht?

dettus

dettus

Bicycle User
Scheiss Apple!

Okay, ich habe gerade folgendes Phaenomen: Ich kann keine Programme laufen lassen, die mit den drei Buchstaben .app enden. Die OS-Version ist 14.2.1 Samononoa-Dingsbums.

Und zwar dieses Programm hier:
Code: 
#include <stdio.h>
#include <stdlib.h>

int main()
{
    printf("hello world!\n");
}

Compiliere ich es so, geht es:
Code: 
gcc -O3 -o hello.exe hello.c ; ./hello.exe
hello world!

Compiliere ich es so, geht es nicht:
Code: 
gcc -O3 -o hello.app hello.c ; ./hello.app
Killed: 9



WTF?
 
Es geht aus Deiner Beschreibung nicht ganz genau hervor, ob das killed sich auf den Kompilierungsvorgang bezieht oder auf den Programmstart. Ich nehme mal an, das ist der Programmstart (weil das auch zu Deiner übrigen Problembeschreibung passt).
Kommen dabei eigentlich auch identische Dateien raus? Sprich ist die Datei hello.exe identisch mit hello.app ?
Tritt das Problem auch auf, wenn Du einen anderen Compiler (clang) benutzt?
 
ldd unter macOS? Vielleicht otool -L <file>? 'which gcc'? 'gcc --version'? Funktioniert es, wenn du die Datei einfach umbenennst? Auf meinem alten Mac (macOS 12.x) funktioniert es.
 
Um Eure Fragen alle zu beantworten: Ja, es ist gleich.
Code: 
; gcc -O3 -o hello.exe hello.c
; cp hello.exe hello.app
; ./hello.exe
hello world!
; ./hello.app
Killed: 9


WIZTIGERWEISE: Wenn ich einen hard link von .exe nach .app mache geht es wieder:

Code: 
; rm hello.app
; ln hello.exe hello.app
; rm hello.exe
; ./hello.app
hello world!
; cp hello.app hello2.app
; ./hello2.app
Killed: 9
; cp hello2.app hello2.exe
; ./hello2.exe
hello world!
 
Deutet ja so ein bisschen darauf hin, das er sich da filename-extension stößt. Das die bewirkt, das er er die Datei an irgendeiner Stelle anders behandelt.
Eventuell ja eine Gelegenheit bei Apples Bug-Bounty-Programm groß abzuräumen. ;-)
 
Kann es daran liegen, dass unter macOS das Verzeichnis der Application .app heißt und darin der ganze Kram der App liegt?
Wenn man einen Rechtsklick auf eine Application macht, erscheint ein Kontextmenü mit dem Eintrag 'Paketinhalt anzeigen'. Wenn man den auswählt sieht man die Verzeichnisstruktur der App.
 
Der Name alleine kann es nicht sein, weil mit den Hard Links geht es ja.
Aber ich habe hier auch nur einen Firmen-Apfel zum Testen. Es kann auch sein, dass da noch ein Virenscanner im Hintergrund Amok laeuft?

Vielleicht kann das einer von Euch MalEbenSchnell(tm) ausprobieren?
 
dettus schrieb:
Der Name alleine kann es nicht sein, weil mit den Hard Links geht es ja.
Zum Vergrößern anklicken....
Naja. Es kommt ja darauf an, welcher Name für den Fehler ausschlaggebend ist. Ob der Name des Hardlinks oder der Name der eigentlichen Datei. Kommt darauf an, wie das System intern damit verfährt. Insofern ist das jetzt keine Sache, die das ausschließt.

dettus schrieb:
Es kann auch sein, dass da noch ein Virenscanner im Hintergrund Amok laeuft?
Zum Vergrößern anklicken....
Könnte gut sein. Wenn ein Virenscanner aktiv ist, kann man ja mal probieren den zu deaktivieren.
 
Ich bin mir ziemlich sicher, dass der Loader in macOS .app Dateien generell als Application Bundle betrachtet und da deine Datei keine ist, bricht er einfach ab. Viele typische CLI Tools in macOS sind angepasst, um mit den Eigenheiten von macOS umzugehen. Auch Dinge wie cp, mv und Co.

Es ist nicht ungewöhnlich, dass er das ausschließlich am Namen fest macht, da ".app"-Dateien keine Dateien sind, sondern Ordner.
 
Was ich leider bei meiner Thread-Eroeffnung vergessen habe zu erwaehnen: Der Apfel, um den es geht, ist mein Firmenrechner.
Da ich auf denen keine Admin-Rechte habe (Na gut, doas, aber das reicht noch nicht, um den Virenscanner deaktivieren.


Daher wuerde ich gerne nochmal die Frage stellen, ob das jemand von Euch auf einem privaten Mac ausprobieren koennte.
 
Ok, ich habe das Problem verifizieren können. Macos 14.2.1. Warum es dazu kommt, kann ich jetzt auch nicht sagen. Dazu bin ich in Macwelt noch zu frisch :-)
 
Ich finde ja, die in #11 gepostete Information (inkl. Link) liefert einen plausiblen Erklärungsansatz.
Die Antworten kommen mir so vor, als ob das keiner zur Kenntnis nimmt. :-)
 
Die Beschreibung in #11 mag ja plausibel sein.. aber das seh ich fuer simple executables noch nicht:
Code: 
╰─$ file restic
restic: Mach-O 64-bit executable x86_64
╰─$ cp restic restic.app
╰─$ ./restic.app --help|head -2

restic is a backup program which allows saving multiple revisions of files and

sym oder hardlink das gleiche spiel: funktioniert.

Der Anteil, der sich hinter "open(1)" versteckt, laesst sich von dem .app suffix in die Irre fuehren und
fuehrt dann "fehlerfrei" nix aus - ohne .app oeffnet es korrekt ein terminal mit dem help output.

Ich glaub der Hint in Richtung virenscanner ist noch nicht tot..
 
Okay, ich habe mittlerweile ein wenig rumprobiert.
In den Macuser Foren habe ich mal ein Shellscript gepostet, das moechte ich auch mit Euch teilen:


Code: 
#/bin/zsh

echo "
Hello!
Thank you for taking a look at this problem.
So, to trigger it, you need to

1. open a new terminal window
2. copy and paste the code below into the new window
3. press CTRL+D in that window
4. press CTRL+D in this window

"
echo "-----------------------------[OPEN A NEW TERMINAL WINDOW, COPY THIS TEXT]---"


echo "cd "`pwd`
echo "cat >one.app
#!/bin/zsh
echo works
"
echo "---[DO NOT FORGET THE LAST LINE, AND TO PRESS CTRL+D IN THE OTHER WINDOW]---"
cat >/dev/null


echo "You just created a script, and the name of the script ends with '.app'"
echo "Now, calling this script causes it to be killed IMMEDIATELY!"
chmod 755 one.app
echo "calling one.app"
./one.app

echo
echo "See? And now look what happens when somebody copies it, and changes the"
echo "name so that it ends in two.exe"
cp one.app two.exe
echo "calling two.exe"
./two.exe
echo
echo "So, one.app and two.exe are IDENTICAL, yet, the OS treats them differently."
echo "Seems strange? Wait till you see what happens with Hard Links!"
ln two.exe three.app
echo "calling three.app"
./three.app
echo
echo "And now this"
cp three.app four.exe
./four.exe
ln one.app five.exe
./five.exe
cp five.exe six.app
./six.app


echo
echo "Neat, huh?"
echo "I will erase the .app and .exe files now, so you can run this script again"
rm one.app two.exe three.app four.exe five.exe six.app
echo "I am currently running Darwin 23.2.0 Darwin Kernel Version 23.2.0: Wed Nov 15 21:53:18 PST 2023; root:xnu-10002.61.3~2/RELEASE_ARM64_T6000 arm64"
echo "It is not a problem of the shell script, it also happens with exectuables"
echo "which I compiled with gcc. So there is something else happening!"
echo
echo "Enjoy finding the bug! Personally, I think it is the best part of my job"

Die Erkenntnis ist, dass es nicht nur binaries betrifft, sondern auch shell-skripte. Das ist schon interessant!
Mittlerweile bin ich soweit, dass das SIGKILL vom launchd kommt. (Was immer das auch ist...)
 
Nimm es mir nicht übel, aber wenn du eine Binary .app nennst, verstößt du gegen die Vorgaben von Apple. Wenn du unter Windows ein Shell Skript .exe nennst, wird dir Windows das auch um die Ohren hauen.

Unabhängig davon, welche Arten du findest den Loader auszutricksen, es bleibt ein Fehlverhalten auf deiner Seite.
 
<nörgel>
dettus schrieb:
Scheiss Apple!
Zum Vergrößern anklicken....
Eigentlich wollte ich nichts dazu schreiben, wenn man schon so saublöd anfängt, aber egal....
</nörgel>

Da braucht man kein dtrace oder dtruss für, das geht auch mit der Konsole. Da zeigt sich dann sowas hier
Code: 
ASP: Security policy would not allow process: 31568, /Users/alexc/test/bin/flac.app

Bei der reservierten Endung .app wird eben auch das Entitlement erwartet. Fehlt das, wird der Prozess halt nicht erlaubt.
Jetzt kann man gerne darüber streiten, ob der Loader das alles richtig macht, denn dasselbe Binary in einem .app Bundle läuft ohne Probleme:
Code: 
 ./flac.app/Contents/MacOS/flac.app

Aber nun gut, das Thema juckt mich auch nicht weiter, kannst ja einen Bug bei Apple melden.

Edit:
Ich gehe mal davon aus, dass im Falle des Bundles nach dem Entitlement gesucht, aber keins gefunden wird und dann das flac.app mit Standard-Entitlements ausgeführt wird. Ohne Bundle (sprich Ordnerstruktur) kann er halt nicht suchen...
 
Wie wäre es denn mit dem umgekehrten Ansatz? Warum willst du denn auf Teufel komm raus, das die Endung unbedingt .app ist?
Wenn dazu mehr Kontext kommt, lässt sich ja vielleicht auch ein anderer Weg aufzeigen, um das eigentliche Ziel zu erreichen.

Ansonsten scheint ja ein Weg offensichtlich. Wenn .app-Dateien Application-Bundles sind, dann liegt es doch nahe Dein Executable in ein solches Bundle zu verpacken.

Diese Dinge sind vielleicht erfolgversprechender, als irgendwelche "Hacks".
 
Andy_m4 schrieb:
Wie wäre es denn mit dem umgekehrten Ansatz? Warum willst du denn auf Teufel komm raus, das die Endung unbedingt .app ist?
Zum Vergrößern anklicken....
1. Warum nicht? ;)
2. Ich bin Unix-ler. Fuer mich sind File-Endings sind Teil des Namens. Der Name sollte irrelevant sein. Wenn ich meine Programme .jpeg nennen moechte, dann sollte mir das OS es nicht verbieten.
3. Ich sehe es als Bug an.

Lass mich Punkt 3 erklaeren: Ja. .app sind bei Aepfeln Verzeichnisse. Mit Programmen drinne, die ein bestimmes Format haben.
Da macht es Sinn, wenn eine Security-Policy laeuft, die das checkt.
Jetzt wundert es mich aber, dass diese Policy auch auf DATEIEN anspringt. Daher die Bug-Hypothese.
 
dettus schrieb:
Ich bin Unix-ler. Fuer mich sind File-Endings sind Teil des Namens. Der Name sollte irrelevant sein. Wenn ich meine Programme .jpeg nennen moechte, dann sollte mir das OS es nicht verbieten.
Zum Vergrößern anklicken....
Ah. Ein Hüter der reinen Lehre. :-)
Das Problem ist ja Folgendes: Wenn Du eine Datei explizit im Stile von progname <filename> aufrust, dann gibt es ja kein Problem. Wenn Du dem System nur filename gibst, das muss es ja nach irgendeinem Regelwerk entscheiden, wie es damit umgehen soll. In die Datei reingucken um den "Typ" zu bestimmen so im Stile von file/libmagic ist potentiell fehleranfällig. Man kann File-Attribute nehmen. Die haben aber den Nachteil, das sie vom Dateisystem abhängig sind. Außerdem sind sie für den Benutzer nicht offensichtlich sichtbar. Insofern finde ich sich an der Dateiendung zu orientieren keine völlig bescheuerte Idee. Wie dem auch sei: Irgendein Unterscheidungsmerkmal brauchst Du.

dettus schrieb:
Daher die Bug-Hypothese.
Zum Vergrößern anklicken....
Man könnte es ja mal mit einem Bug-Report versuchen. Mal sehen, was Apple dazu sagt.
 
Also was Du Dir so vorstellst (assumption is the mother of all FU..) ist nicht sonderlich relevant.
Darauf als "bug" rumzureiten waere so schlaubergerisch wie zu Verlangen, dass man den shebang anders
schreibt/benutzt/... (was teilweise sogar geht, aber siehe auch Andy_m4 dazu).
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben