Zugriffsrechte, die ewige Geißel des Apfels?

[MacApple]

Wieso schreibt Apple dann im Fenster des Festplattendienstprogrammes, daß die Rechtereparatur für alle Programme gilt, die mit dem Apple-Installationsprogramm installiert wurden?

Lies mal genau. Da steht nämlich „Mac OS X-Installationsprogramm“. Das ist das Programm, was beim booten von der System-DVD gestartet wird.

Oder sprichst du von Installationsprogrammen von Drittanbietern?

Nein, ich meine schon normale Packages für das „Installationsprogramm” (ohne Mac OS X davor).

Gibt es da überhaupt noch welche?

Ja, es gibt immer noch so ein paar ewig gestrige. Ich sag nur Adobe.

MacApple

 

[MacAlzenau]

Lies mal genau. Da steht nämlich „Mac OS X-Installationsprogramm“. Das ist das Programm, was beim booten von der System-DVD gestartet wird.

Ich interpretiere das auch beim genauen Lesen als das Installationsprogramm, das Mac OS X verwendet.

 

[Macbeatnik]

Lies mal genau. Da steht nämlich „Mac OS X-Installationsprogramm“. Das ist das Programm, was beim booten von der System-DVD gestartet wird.

Nur damit nicht noch mehr durcheinandergeworfen wird, hier die genaue Beschreibung, aus der Hilfe des Festplattendienstprogramms, habe ich weiter unten schon mal gepostet:

Das Festplatten-Dienstprogramm repariert die Zugriffsrechte für Dateien, die vom Installationsprogramm oder der Systemeinstellung "Softwareaktualisierung" installiert wurden. Zugriffsrechte für Ihre Dokumente, Ihren Benutzerordner und bestimmte Programme von Drittanbietern, einschließlich Programme, die nicht im Installationsprogramm installiert werden, werden nicht repariert.

Damit sollten dann alle zweifel was die Zugriffsrechtsreparatur anpackt beseitigt sein oder?

 

[MacApple]

Ich interpretiere das auch beim genauen Lesen als das Installationsprogramm, das Mac OS X verwendet.

Wenn Du es nicht glaubst, dann bau Dir doch einfach mal mit dem PackageMaker ein Paket, installiere es, ändere ein paar Rechte an den installierten Dateien und lass die Rechte reparieren. Du wirst sehen, danach sind die Rechte immer noch verstellt.

MacApple

 

[Rastafari]

...meinen Fileserver auflöste (lief unter Linux), kopierte ich alle Dateien auf verschiedene Festplatten...

Gretchenfrage: welches Dateisystem haben die?

 

[Rastafari]

Wie ich oben schon schrieb, interessiert sich die Rechterreparatur nicht im Geringsten für fremde Installationspakete.

Das war gestern. Werden sie mit dem Apple Installationsprogramm eingespielt, kann man sie schön *alle* mitnehmen bei der Aktion. Das funktioniert prinzipiell auch schon jetzt.
(Nur leider macht bisher fast kein Developer davon Gebrauch - das neue Leo Paketformat verträgt sich nicht mehr mit Tiger). Bisher ist es noch so gehandhabt, dass externe Pakete nur überprüft werden, wenn man den Vorgang manuell an der Kommandozeile anzündet.

man repair_packages

Freu dich ob der Dinge die da kömmen werden:
- Support für *.deb Pakete
- Support für *.rpm Pakete
- Auflösung von Abhängigkeiten und Querbezügen
- Deinstallation, die auch funktioniert.
- Signierte Installationspakete als Standard
- Festplattenschnappschüsse zur schnellen Rekonstruktion nicht mehr bootfähiger Systeme.
Fragt sich halt immer nur.... wann?

 

[naich]

- Deinstallation, die auch funktioniert.

Also wenn sie das nicht absolut sauber einbauen (+ eine zentrale Anlaufstelle! dafür), wann wäre das schon ein ganz schön großer Rückschritt...

Das installierten per Drag and Drop finde ich einer der besten Unterschiede zu Windows.

 

[MacMark]

... Das installierten per Drag and Drop finde ich einer der besten Unterschiede zu Windows.

Es hat allerdings den Nachteil, daß die Rechte in /Applications/NeuesProgramm.app nicht stimmen nach Drag & Drop. Korrekt wären sie root:admin, tatsächlich sind sie aber AdminUserXy:admin.

 

[n/a]

Gretchenfrage: welches Dateisystem haben die?

Unter Linux liefen sie auf ext2 oder 3 und auf dem Mac sind sie jetzt under HFS+ Journaled formatiert. Die Dateirechte wurden per rsync wohl von der Linuxplatte mitgenommen und dann gab es hier etwas Kuddelmuddel. Per Terminal habe ich dann die Benutzer für alle Dateien und Ordner korrigiert (chown und chmod mit -r) aber es hat nicht überall geklappt.

 

[MacAlzenau]

Wenn Du es nicht glaubst, dann bau Dir doch einfach mal mit dem PackageMaker ein Paket, installiere es, ändere ein paar Rechte an den installierten Dateien und lass die Rechte reparieren. Du wirst sehen, danach sind die Rechte immer noch verstellt.

MacApple

Dann ist das aber ein Fehler im System (oder von Seiten der Drittprogramm-Entwickler), denn es steht halt anders da, als es wirklich ist.
(Wobei ich zugebe: es steht ja nicht da, daß was repariert wird, nur daß man die Funktion benutzen soll...)

 

[Rastafari]

jetzt under HFS+ Journaled formatiert.

Dann wendest du erst mal folgendes drauf an:

sudo chflags -R nouchg "/Volumes/Meine Disk"
sudo chmod -RN "/Volumes/Meine Disk"

 

[Rastafari]

Dann ist das aber ein Fehler im System (oder von Seiten der Drittprogramm-Entwickler)

Letzteres.
Wollten die ihre Pakete repariert haben, bräuchten sie nur eine Zeile in ihre postinstall-Skripte zu packen:

/usr/libexec/repair_packages --pkg <[I]BUNDLE-ID[/I]>

Und schon wäre man "drin" in der Liste.

 

[MacApple]

Das war gestern.

Nein, das ist der heutige Stand der Dinge, denn...

Bisher ist es noch so gehandhabt, dass externe Pakete nur überprüft werden, wenn man den Vorgang manuell an der Kommandozeile anzündet.

man repair_packages

...der typische Mac User macht das eben nicht. Man muss dazu nämlich auch die Package-IDs herausfinden und man muss repair_packages finden, welches nicht in den Standard Suchpfaden (PATH) zu finden ist.

Das ist es auch, was mich hier an den Empfehlungen für die Allgemeinheit stört. Ich musste erst richtig nachbohren, bis hier mal die wichtigen Details auf den Tisch gelegt werden und dass hier teilweise von zukünftigen Systemen geredet wurde. Wenn man sich die Details dann genau anschaut stellt man fest, dass die ursprünglichen Empfehlungen (hier Reparatur der Zugriffsrechte mit dem Festplatten-Dienstprogramm) in der Praxis dann doch nicht das bewirken, was hier suggeriert wurde, weil eben die wichtigen Details verschwiegen wurden. Wenn Ihr schon etwas im Namen der Sicherheit empfehlt, dann macht es vollständig. Ansonsten kann man sich das auch gleich sparen und wiegt den typischen Mac User in falscher Sicherheit.

Freu dich ob der Dinge die da kömmen werden:

Ich freue mich erst, wenn das alles wirklich da ist. Ob das alles nämlich wirklich kommt, weiß nur Apple.

MacApple

 

[n/a]

Dann wendest du erst mal folgendes drauf an:

sudo chflags -R nouchg "/Volumes/Meine Disk"
sudo chmod -RN "/Volumes/Meine Disk"

Nun gut, danke und werde ich gerne machen aber ich wüsste gerne vorher, was das genau bewirkt .

 

[MacApple]

Letzteres.
Wollten die ihre Pakete repariert haben, bräuchten sie nur eine Zeile in ihre postinstall-Skripte zu packen:

/usr/libexec/repair_packages --pkg <[I]BUNDLE-ID[/I]>

Und schon wäre man "drin" in der Liste.

Schon mal ausprobiert? Wohl nicht, denn dann wüstest Du, dass dieses Kommando ein

repair_packages: An action must be specified.

zur Folge hätte.

Usage: repair_packages [ARGUMENTS]...

Commands:
   --help                Print this usage guide.
   --list-standard-pkgs  Display the package ids in the standard set.
   --verify              Verify permissions on files in the specified package(s).
   --repair              Repair permissions on files in the specified package(s).
Options:
   --pkg PKGID           Verify or repair the package PKGID.
   --standard-pkgs       Verify or repair the standard set of packages.
   --volume PATH         Perform all operations on the specified volume.
   --output-format #     Print progress info using a special output format.
   --debug               Print debuging information while running.

MacApple

 

[Rastafari]

Nun gut, danke und werde ich gerne machen aber ich wüsste gerne vorher, was das genau bewirkt .

"Geschützt"-Attribut und ACLs entfernen (rekursiv).

 

[Rastafari]

Schon mal ausprobiert? Wohl nicht, denn dann wüstest Du, dass dieses Kommando ...

...dieses verkürzte Kommando... "man" hilft dir in den Schuh.

[size=2]admin@Minimax[~]$ sudo /usr/libexec/repair_packages --pkg org.nutheadz.eyecaramba.pkg --repair --volume /
Verifying files from package 'org.nutheadz.eyecaramba.pkg' on '/'.
	ACL found but not expected on 'Applications/Utilities/.'.
	Repaired "Applications/Utilities/.".
Finished verifying files from package 'org.nutheadz.eyecaramba.pkg' on '/'.
admin@Minimax[~]$[/size]

Und funzt.

 

[MacApple]

...dieses verkürzte Kommando... "man" hilft dir in den Schuh.

[size=2]admin@Minimax[~]$ sudo /usr/libexec/repair_packages --pkg org.nutheadz.eyecaramba.pkg --repair --volume /
Verifying files from package 'org.nutheadz.eyecaramba.pkg' on '/'.
	ACL found but not expected on 'Applications/Utilities/.'.
	Repaired "Applications/Utilities/.".
Finished verifying files from package 'org.nutheadz.eyecaramba.pkg' on '/'.
admin@Minimax[~]$[/size]

Und funzt.

Sorry, aber das hat überhaupt nichts mit einem Postinstallscript zu tun. Damit lässt Du ein Paket direkt reparieren.
Du wolltest ein Installationspaket mit in die Liste der zu reparierenden Pakete aufnehmen lassen, damit das Festplatten-Dienstprogramm das Paket mit berücksichtigt. Und da nützt Dir auch keine manpage, denn das geht einfach nicht. Damit musst Du Dich aktuell wohl oder übel abfinden.

MacApple

 

[Rastafari]

Sorry, aber das hat überhaupt nichts mit einem Postinstallscript zu tun. Damit lässt Du ein Paket direkt reparieren.

Es hat sich in der dafür nötigen Gruppe zu registrieren.
Dann einmal einen verify- oder repairlauf durchgeführt und es ist in die Liste aufgenommen.
Erzähl mir nicht was geht und was nicht geht, denn die von mir selbst erstellten Pakete WERDEN repariert.
Ausser meinen eigenen Projekten habe ich aber bisher genau *zwei* Fremdanbieter finden können, die überhaupt schon auf das neue Flatpackage-Format von Leo umgestellt haben. (Geschweige denn sie korrekt einzutragen...)
So wird das natürlich nix, aber das ist nicht Apples Schuld. Punkt.

 

[MacApple]

Es hat sich in der dafür nötigen Gruppe zu registrieren.
Dann einmal einen verify- oder repairlauf durchgeführt und es ist in die Liste aufgenommen.
Erzähl mir nicht was geht und was nicht geht, denn die von mir selbst erstellten Pakete WERDEN repariert.

Seufz, das „aus der Nase ziehen“ geht weiter. Oben hast Du nur ein einziges Kommando für ein Postinstallscript hingeschrieben:

/usr/libexec/repair_packages --pkg <package-ID>

So, wenn ich dieses Kommando mal abschicke, bekomme ich halt eine Fehlermeldung (siehe oben). Aber das Kommando verhält sich vermutlich als Postinstallscript komplett anders, nicht wahr?

MacApple