Restic: MacOS Mojave: Fehler: Öffnen: ... Vorgang nicht erlaubt

Ja, anscheinend müssen Sie die Sache mit dem vollständigen Festplattenzugriff machen: https://www.backblaze.com/blog/mojave-permissions/

Sind Sie _sicher_, dass Sie die richtige Restic-Binärdatei hinzugefügt haben? Haben Sie die Datei verschoben oder eines ihrer Attribute (Eigentum usw.) geändert, nachdem Sie sie in den Systemeinstellungen zu „Voller Festplattenzugriff“ hinzugefügt haben?

(Ich habe einen Mac, aber ich habe noch kein Mojave, tut mir leid.)

Ich verwende Homebrew, also fügte ich zuerst /usr/local/bin/restic zu Full Disk Access hinzu, startete einen Job, bemerkte die gleichen Fehler, also entfernte ich das und fügte den Pfad zur eigentlichen Binärdatei hinzu (wobei ich feststellte, dass dies leider sein müsste jedes Mal wiederholt restic Updates): /usr/local/Cellar/restic/0.9.2/bin/restic , leider sehe ich die gleichen Fehler.

Keine Änderungen, Binärdatei zu Full Disk Access hinzugefügt, zurück zum Terminal gewechselt und sudo myscript.sh , was für die meisten Dateien funktionierte, aber bei anderen Berechtigungsfehler verursachte.

Randbemerkung, es gibt ein weiteres (möglicherweise Mojave-bezogenes) Problem, das ich zu konkretisieren versuche, wo meine sftp-Pubkey-Authentifizierung nicht mehr funktioniert, wenn sie von launchctl (als root) ausgeführt wird, aber funktioniert, wenn sie manuell als root ausgeführt wird, aber ich werde Melden Sie ein neues Problem, wenn ich feststellen kann, dass es nicht spezifisch für mein Setup ist.

Interessant. Was passiert, wenn Sie restic direkt ausführen? Und/oder fügen Sie Ihr Skript der FDA hinzu. Ich schieße hier ehrlich gesagt nur im Dunkeln. Wenn ich Mojave hätte, würde ich es ausprobieren.

Guter Gedanke.

Mein Skript selbst ist nicht ausführbar (eigentlich ohne guten Grund), wie bereits erwähnt, führe ich es mit sudo bash myscript.sh aus (eigentlich /usr/local/bin/bash ); Es kann nicht zu FDA hinzugefügt werden, da es nicht ausführbar ist.

Ich habe versucht, /usr/local/bin/bash zu FDA hinzuzufügen und keine Würfel.

BEARBEITEN: Ich liege anscheinend falsch, selbst nach chmod +x kann mein backup.sh immer noch nicht direkt zur FDA hinzugefügt werden (während die Binärdateien bash und restic kann). Seltsam.

EDIT2: Nur um gründlich zu sein, ich habe die Binärdateien bash und restic beide zur FDA hinzugefügt und sehe den gleichen Fehler.

Wahrscheinlich ein größeres Problem als Restic - ich habe sogar versucht, /bin/ls zur FDA-Liste hinzuzufügen, und bekomme immer noch eine Fehlermeldung.

$ sudo /bin/ls /Users/me/Library/Suggestions
ls: Suggestions: Operation not permitted

BEARBEITEN: Hässliche Problemumgehung: Fügen Sie den FDA-Berechtigungen Terminal.app hinzu und die Berechtigungsfehler verschwinden.

Relevanter Thread: https://forums.developer.apple.com/thread/107546

Ich habe versucht, codesign sowohl die Restic-Binärdatei als auch mein backup.sh -Skript zu schreiben und zur FDA hinzuzufügen, kein Glück.

(Nachdem ich etwas von diesem Thread gelesen habe) Meine Güte. Das ist super nervig. Danke, dass Sie sich darum gekümmert haben! Ich werde auch weiter nachforschen, sobald ich ein Upgrade habe ...

Wow, vielen Dank für die Informationen und all die Zeit, die Sie für das Problem aufgewendet haben! Ich habe überhaupt keinen Mac, also bin ich froh, wenn Sie beide es herausfinden könnten und wir dieses Problem für andere Benutzer dokumentieren können! Danke nochmal!

@mholt Wenn Sie möchten, können Sie eine 30-Tage-Testversion von VMware Fusion installieren und darin Mojave installieren (es sei denn, Apple hat die Fähigkeit zur Ad-hoc-Installation eingeschränkt). Diese Testversion verursacht keine Verschmutzung und kann deinstalliert werden, wenn Sie sie später nicht möchten.

Ich habe oben angemerkt , dass das Hinzufügen Terminal.app zur Liste System Preferences -> Security & Privacy -> Full Disk Access eine Problemumgehung war, da ich mein Skript manuell ausgeführt habe ( sudo /usr/local/bin/bash mybackup.sh ) schien es ohne die Berechtigungsfehler zu funktionieren.

Als ich heute Morgen meine Protokolle vom automatisierten Restic-Lauf über Nacht überprüft habe (basierend auf einem launchd -Skript bei /Library/LaunchDaemons/com.n8henrie.restic.plist , das jede Nacht mit Root-Rechten ausgeführt wird), sind die Berechtigungsfehler aus irgendeinem Grund immer noch da.

Und leider kann ich die Problemumgehung jetzt nicht zum Laufen bringen - selbst mit Terminal.app in der FDA erhalte ich immer noch die Berechtigungsfehler, wenn ich sudo launchctl start com.n8henrie.restic oder sudo /usr/local/bin/bash mybackup.sh ausführe.

Die Problemumgehung scheint also nicht zu funktionieren, oder es hat sich etwas geändert.

BEARBEITEN: Gah, ich habe gerade alle 3 zur FDA hinzugefügt - Terminal.app , /usr/local/bin/bash und /usr/local/Cellar/restic/0.9.2/bin/restic - und jetzt lief es ohne Fehler. 🤷‍♂️

FWIW, hier ist meine Protokollausgabe , die die Liste der Dateien enthält, die Fehler erhalten. Wie Sie sehen können, gibt es einige große Bedenken, wie meine Fotobibliothek.

@n8henrie Aus dem Mac-Support-Thread, den Sie zuvor verlinkt haben, scheint es, dass die FDA verlangt, dass die zugelassenen Apps ein registriertes .app-Bundle im Anwendungsordner sind, was möglicherweise der Grund dafür ist, dass Terminal.app erfolgreich ist ... aber Sie müssen alle 3 hinzufügen in Ihrem Fall an die FDA? Interessant...

@mholt es sieht so aus, als ob etwas anderes vor sich geht. Ich habe meine Einstellungen genau so gelassen, wie sie gestern waren (alle 3 in FDA, die keine Berechtigungsfehler erzeugten), und mein nächtlicher Lauf hat immer noch die gleichen alten Berechtigungsfehler.

Dies ist jetzt zweimal passiert, wo ich nach einer Weile Basteln Läufe ohne Berechtigungsfehler bekomme, die dann wieder auftauchen. Weiß restic irgendwie, ob sich eine Datei geändert hat oder nicht, ohne die Datei öffnen zu müssen - eine Art Cache? Ich frage mich, ob ich mich von Läufen täuschen lasse, die eng beieinander liegen, und es wurden keine zwischenzeitlichen Änderungen an einer Datei vorgenommen, und deshalb versucht restic nicht, sie zu öffnen?

Ansonsten fällt es mir schwer zu erklären, was hier vor sich geht.

Gute Frage. Ich weiß, dass Restic einen Cache verwendet, aber ich habe nicht untersucht, wie aggressiv es bei Berechtigungsfehlern usw. daran festhält.

Relevante Diskussion unter SO: https://apple.stackexchange.com/q/338213/27415

Gute Frage. Ich weiß, dass Restic einen Cache verwendet, aber ich habe nicht untersucht, wie aggressiv es bei Berechtigungsfehlern usw. daran festhält.

Keineswegs. Der Cache enthält nur Dateien aus dem Repo, es sind keine Informationen über das Dateisystem (das sich nicht im Repo befindet) enthalten.

Okay - ja, ich glaube nicht, dass das ein Fehler in Restic ist. Dies ist definitiv ein macOS Mojave-Problem, bei dem ich mir zu diesem Zeitpunkt ziemlich sicher bin, dass restic selbst nichts tun kann, um es zu beheben.

Cool, danke für das Feedback, ich schließe dieses Thema vorerst. Bitte fügen Sie weitere Kommentare hinzu, wenn Sie Dinge herausfinden. Danke!

Ich bin ein wenig überrascht zu sehen, dass das Problem bereits geschlossen ist – das scheint eine
große Inkompatibilität mit einer großen Plattform und schließen sie an dieser Stelle
kann es "aus den Augen, aus dem Sinn" sagen.

Ich verstehe, dass dies nicht in erster Linie ein Restic-Problem ist, aber es scheint so
Es gibt einige vernünftige Schritte, die für MacOS-Benutzer unternommen werden könnten. Wie es ist,
die Fähigkeit eines Benutzers, einen Großteil seiner wichtigsten persönlichen Daten zu sichern
Daten (z. B. Fotos) werden standardmäßig auf der aktuellen Version von kompromittiert
Mac OS. Das scheint mir für jede Backup-Software eine große Sache zu sein!

Einige Vorschläge/Möglichkeiten (bei denen ich gerne mitarbeite):

• Möglichkeiten zur Behebung des Problems
  
  
  
  • Ist es möglich, eine geeignete MacOS-Wrapper-Anwendung bereitzustellen, die
    
    kann zur FDA-Liste hinzugefügt werden, die die Restic-Binärdatei enthält
  
  
  • Wenn Sie herausfinden können, wie das oben Gesagte zu tun ist, anstatt die bereitzustellen
    
    Anwendung, könnten wir Anweisungen dafür enthalten, wie Benutzer dies erreichen können
    
    selbst mit einer Art Makefile oder XCode?
  
  
• Problemumgehungen
  
  
  
  • Geben Sie in den Dokumenten Informationen zu den sichersten / minimalsten Binärdateien an
    
    die der FDA hinzugefügt werden müssen
  
  
  • Stellen Sie Links zu Informationen bezüglich (und Risiken der) Deaktivierung von SIP bereit
  
  
• Warnungen
  
  
  
  • Fügen Sie Informationen irgendwo in die Dokumentation ein, die Mojave-Benutzer nicht haben werden
    
    ihre Daten standardmäßig vollständig gesichert
  
  

Insgesamt scheint die Situation einer vollständigen Sicherung ohne Root nicht allzu unähnlich zu sein
unter Linux, wobei das Deaktivieren von SIP insgesamt so etwas wie das Ausführen als ist
root und Bestimmen und Empfehlen eines einigermaßen sicheren Kompromisses mit
FDA ist so etwas wie die Verwendung setcap .

Leider ist mein Macbook diese Woche im Shop, also kann ich nicht
Ich arbeite sofort an einem davon, aber ich wäre daran interessiert, Gedanken zu hören
von anderen; Vielleicht bin ich weit weg von der Basis oder möglicherweise unwissend über Einzelheiten von
der Restic-Team-Workflow zum Verwalten von Problemen.

Jetzt, da ich meine Maschine wieder habe, noch ein paar Updates:

Ich kann meine oben genannten Erfolge beim Abrufen einer vollständigen Systemsicherung von meinem launchd-Skript nicht replizieren.

Ich habe versucht, alle der folgenden Punkte (gleichzeitig) zur FDA-Liste hinzuzufügen, und erhalte immer noch die Fehler:

• Rest
• bash
• launchctl
• launchd
• Terminal.app

Nur zum Experimentieren scheinen nackte Binärdateien gut zu funktionieren, wenn sie der FDA-Liste hinzugefügt werden, und scheinen nichts mit Codesign zu tun zu haben. Vergleichen Sie die ls Binärdateien, die von MacOS und Homebrew bereitgestellt werden:

$ codesign -d /bin/ls
Executable=/bin/ls
$ codesign -d /usr/local/opt/coreutils/libexec/gnubin/ls
/usr/local/opt/coreutils/libexec/gnubin/ls: code object is not signed at all

Vor und Hinzufügen zur FDA-Liste:

$ /bin/ls ~/Library/Mail
ls: Mail: Operation not permitted
$ /usr/local/opt/coreutils/libexec/gnubin/ls ~/Library/Mail
ls: cannot open directory '/Users/n8henrie/Library/Mail': Operation not permitted
$ # Added to FDA
$ /bin/ls ~/Library/Mail
PersistenceInfo.plist V6
$ /usr/local/opt/coreutils/libexec/gnubin/ls ~/Library/Mail
PersistenceInfo.plist  V6

Außerdem funktionieren sie gut, wenn sie in ein Bash-Skript eingefügt werden, solange ls in der FDA ist (keine Notwendigkeit, bash separat hinzuzufügen), was mich denken lässt, dass ich nur restic hinzufügen muss

Zum Vergleich werden auch die folgenden Go-Skriptfehler ausgeführt, wenn sie nicht in der FDA sind, aber sie funktionieren sowohl von sich aus als auch, wenn sie von launchd aufgerufen werden, solange sich die Binärdatei in der FDA befindet (keine Notwendigkeit, launchd / launchctl / irgendetwas anderes hinzuzufügen).

package main

import (
    "fmt"
    "io/ioutil"
)

func main() {
    matches, err := ioutil.ReadDir("/Users/n8henrie/Library/Mail")
    if err != nil {
        fmt.Println("Err:", err)
    } else {
        for _, match := range matches {
            fmt.Println(match.Name())
        }
    }
}

Ausgabe:

$ ./gotest
Err: open /Users/n8henrie/Library/Mail: operation not permitted
$ # Add to FDA
$ ./gotest
.DS_Store
PersistenceInfo.plist
V6

Als nächstes werde ich mit Restic experimentieren, um herauszufinden, warum es Berechtigungsfehler gibt, selbst wenn es zu FDA hinzugefügt wird (obwohl andere Binärdateien zu funktionieren scheinen, nachdem sie hinzugefügt wurden).

Okay, danke für die Rückmeldung! Ich werde dieses Problem erneut öffnen, vielleicht können wir herausfinden, was los ist, und dann dem Handbuch etwas Dokumentation hinzufügen.

~Bekomme immer noch Open Fehler bei einem neuen Repo, wobei restic zur FDA-Liste hinzugefügt wurde.~

Siehe Bearbeiten unten.

$ restic -r /tmp/restic backup ~/Library/Mail -vvv
open repository
enter password for repository:
repository 9ccb5357 opened successfully, password is correct
created new cache in /Users/me/Library/Caches/restic
lock repository
load index files
start scan on [/Users/me/Library/Mail]
start backup on [/Users/me/Library/Mail]
scan: Open: open /Users/me/Library/Mail: operation not permitted
scan finished in 1.849s: 0 files, 0 B
can not obtain extended attribute com.apple.quarantine for /Users/me/Library/Mail:
error: Open: open /Users/me/Library/Mail: operation not permitted
new       /Users/me/Library/, saved in 0.012s (0 B added, 13 B metadata)
new       /Users/me/, saved in 0.012s (0 B added, 381 B metadata)
new       /Users/, saved in 0.013s (0 B added, 379 B metadata)

Files:           0 new,     0 changed,     0 unmodified
Dirs:            3 new,     0 changed,     0 unmodified
Data Blobs:      0 new
Tree Blobs:      4 new
Added to the repo: 1.119 KiB

processed 0 files, 0 B in 0:01
snapshot 4a658c73 saved
$ restic -r /tmp/restic ls latest
enter password for repository:
repository 9ccb5357 opened successfully, password is correct
snapshot 4a658c73 of [/Users/me/Library/Mail] filtered by [] at 2018-11-04 11:30:05.334024 -0700 MST):
/Users
/Users/me
/Users/me/Library

BEARBEITEN: Ignorieren Sie diesen Kommentar – ich werde immer noch von zeitweiligen Fehlern geplagt, die jeden Fortschritt verwirren, vielleicht im Zusammenhang mit der gestrigen Aktualisierung auf MacOS 10.14.1. Heute funktioniert derselbe Go-Code von gestern, der konsequent mit der FDA funktionierte und ohne ihn fehlschlug (ich habe ihn mehrmals ein- und ausgeschaltet, um sicherzugehen) , nicht mehr, selbst mit der FDA . Dasselbe gilt für ls .

Es funktioniert, wenn Terminal.app zur FDA hinzugefügt wird (als einziger Eintrag), was gestern nicht nötig war.

🤷‍♂️

Ich melde mich wieder, wenn ich dazu etwas in den Apple-Foren finde.

EDIT2: Das Macbook der Frau ist immer noch auf 10.14 und /bin/ls ~/Library/Mail funktioniert nicht mit /bin/ls , das der FDA hinzugefügt wurde, also scheint es in 10.14.1 nichts Neues zu sein. 😕

Daran wird noch gearbeitet.

Es ist weiterhin ziemlich schmerzhaft, aber ich habe endlich eine Problemumgehung, von der ich denke, dass sie für meine Zwecke funktioniert.

Ich habe den Prozess hier detailliert beschrieben, aber die Quintessenz ist:

Sie können Script Editor.app verwenden, um ein AppleScript in ein Anwendungspaket zu verwandeln. Dieses AppleScript kann Ihr Restic-Sicherungsskript ausführen (in meinem Fall /path/to/restic-backup.sh , wobei restic-backup.sh ein Bash-Skript ist, das Restic mit meinen gewünschten Einstellungen ausführt), und Sie können das resultierende Anwendungspaket der FDA hinzufügen um Zugriff auf die geschützten Dateien zu erhalten.

Dies macht es jedoch schwierig, laufende Sicherungen auf Systemebene zu automatisieren. Der integrierte open -Befehl funktioniert, führt die Anwendung jedoch unter Ihrem Benutzer aus – während also die FDA-geschützten Dateien oben gesichert werden, erhalten Sie Berechtigungsfehler für alle Dateien, die nur für Root lesbar sind (z -eigenes 0600-Zeug).

Meine Problemumgehung an dieser Stelle besteht darin, das AppleScript das Backup-Skript mit sudo aufrufen zu lassen und meinem Benutzer die Rechte zu geben, dieses Skript mit Root-Rechten ohne Passwort auszuführen ( sudo visudo , NOPASSWD: , etc.).

Es ist nicht schön, aber es scheint zu funktionieren.

Ich möchte dies für Vorschläge von MacOS-Benutzern mit mehr Fachwissen offen lassen. Wenn nichts Befriedigenderes auftaucht, könnte ich diese Informationen zu den Dokumenten hinzufügen (obwohl diese Lösung ehrlich gesagt nicht sehr zufriedenstellend erscheint).

Unglaublich, das scheint zu funktionieren und ist viel sauberer und einfacher.

// Runrestic provides a binary to run my restic backup script in MacOS Mojave with Full Disk Access
package main

import (
    "log"
    "os"
    "os/exec"
    "path/filepath"
)

func main() {
    ex, err := os.Executable()
    if err != nil {
        log.Fatal(err)
    }
    dir := filepath.Dir(ex)
    script := filepath.Join(dir, "restic-backup.sh")
    cmd := exec.Command("/usr/local/bin/bash", script)
    if err := cmd.Run(); err != nil {
        log.Fatal(err)
    }
}

Die resultierende Binärdatei kann chown root und chmod 0700 sein und dann zu Full Disk Access hinzugefügt werden, und es scheint zu funktionieren. Es kann dann zu einer /Library/LaunchDaemons plist hinzugefügt werden, um automatisch ausgeführt zu werden.

Die ersten beiden Läufe funktionieren bisher, ich hoffe, dass dies nicht wie oben bei mehreren Fehlstarts endet.

• https://apple.stackexchange.com/a/343260/27415

Mein automatischer Lauf gestern Abend hat funktioniert. Ich setze diese Strategie heute auf dem Macbook Air meiner Frau ein, wenn es so aussieht, als ob es dort auch funktioniert, werde ich dies als eine vernünftige Lösung betrachten und an einer kleinen PR für https://github.com/restic/restic arbeiten. net (wenn das sinnvoll erscheint).

Hallo @n8henrie , ich bin hierher gekommen, nachdem ich genau auf dieses Problem gestoßen bin und dann Ihren Blog-Beitrag gefunden habe. Vielen Dank für all diese Recherchen.

Die obige Lösung (Shell-Skript aus einfacher Go-Binärdatei aufrufen) funktioniert bei mir nicht. Sind Sie sicher, dass es erfolgreich auf alle Ihre Dateien zugreift?

Ich bemerke insbesondere, dass stdout/stderr nach /dev/null verworfen wird. Es kann auch stdin nicht lesen, wenn beispielsweise restic nach einem Passwort fragen möchte. (Auch irgendwie lustig, warum ist dein Bash /usr/local/bin/bash und nicht /bin/bash ? Nur neugierig.)

Wie auch immer, ich habe die folgenden Änderungen vorgenommen, um die Fehlerausgabe zu sehen:

    cmd := exec.Command("/bin/bash", script)
    cmd.Stdin = os.Stdin
    cmd.Stdout = os.Stdout
    cmd.Stderr = os.Stderr

Bevor ich Ihren Blogbeitrag sah, war mein erster Instinkt, die Restic-Binärdatei selbst zur FDA hinzuzufügen, und das hat bei mir unter 10.14.1 (18B75) nicht funktioniert. Ich bin mir nicht sicher, warum das Einfügen eines anderen Programms (der Go-Wrapper, der ein Shell-Skript aufruft und letztendlich restic aufruft) etwas ändern würde.

Funktioniert das bei dir noch?

@n8henrie danke, dass du uns auf dem Laufenden gehalten hast! Du könntest auch einen Blogpost darüber im restic Blog schreiben, wenn du Lust dazu hast (zusätzlich zu einem kleinen Abschnitt im Handbuch oder so)... :)

@fd0 Ich würde mich geehrt fühlen!

@armhold ja, scheint wie ein Zauber zu funktionieren, siehe unten. Beim MBA meiner Frau brauchte ich, glaube ich, einen Neustart, bevor er funktionierte (allerdings nicht bei mir). IIRC für sie, ich habe die Binärdatei erstellt, dann neu gestartet, dann zur FDA hinzugefügt, und es hat funktioniert.

Vor der Reparatur:

Thu Nov 15 02:00:00 MST 2018 :: Starting restic-backup.sh
can not obtain extended attribute com.apple.rootless for /Library/Application Support/com.apple.TCC:
error: Open: open /Library/Application Support/com.apple.TCC: operation not permitted
error: open /Library/Preferences/com.apple.TimeMachine.plist: operation not permitted
error: Open: open /Users/me/Library/Application Support/AddressBook: operation not permitted
error: Open: open /Users/me/Library/Application Support/CallHistoryDB: operation not permitted
error: Open: open /Users/me/Library/Application Support/CallHistoryTransactions: operation not permitted
error: Open: open /Users/me/Library/Application Support/MobileSync: operation not permitted
error: Open: open /Users/me/Library/Application Support/com.apple.TCC: operation not permitted
error: Open: open /Users/me/Library/Calendars: operation not permitted
error: Open: open /Users/me/Library/Containers/com.apple.Home: operation not permitted
error: Open: open /Users/me/Library/Containers/com.apple.Safari: operation not permitted
error: Open: open /Users/me/Library/Containers/com.apple.VoiceMemos: operation not permitted
error: Open: open /Users/me/Library/Containers/com.apple.iChat: operation not permitted
error: Open: open /Users/me/Library/Containers/com.apple.mail: operation not permitted
error: Open: open /Users/me/Library/Containers/com.apple.news: operation not permitted
error: Open: open /Users/me/Library/Containers/com.apple.stocks: operation not permitted
can not obtain extended attribute com.apple.quarantine for /Users/me/Library/Cookies:
error: Open: open /Users/me/Library/Cookies: operation not permitted
error: Open: open /Users/me/Library/HomeKit: operation not permitted
error: Open: open /Users/me/Library/IdentityServices: operation not permitted
can not obtain extended attribute com.apple.quarantine for /Users/me/Library/Mail:
error: Open: open /Users/me/Library/Mail: operation not permitted
error: Open: open /Users/me/Library/Messages: operation not permitted
error: Open: open /Users/me/Library/Metadata/CoreSpotlight: operation not permitted
error: Open: open /Users/me/Library/Metadata/com.apple.IntelligentSuggestions: operation not permitted
can not obtain extended attribute com.apple.metadata:com_apple_backup_excludeItem for /Users/me/Library/PersonalizationPortrait:
error: Open: open /Users/me/Library/PersonalizationPortrait: operation not permitted
error: open /Users/me/Library/Preferences/com.apple.AddressBook.plist: operation not permitted
error: open /Users/me/Library/Preferences/com.apple.AddressBook.plist.KaSTvBv: operation not permitted
error: open /Users/me/Library/Preferences/com.apple.AddressBook.plist.M410OmB: operation not permitted
error: open /Users/me/Library/Preferences/com.apple.AddressBook.plist.Sjhd5Xh: operation not permitted
error: open /Users/me/Library/Preferences/com.apple.AddressBook.plist.ceAM0im: operation not permitted
error: open /Users/me/Library/Preferences/com.apple.homed.notbackedup.plist: operation not permitted
error: open /Users/me/Library/Preferences/com.apple.homed.plist: operation not permitted
error: open /Users/me/Library/Preferences/com.apple.mail-shared.plist: operation not permitted
error: Open: open /Users/me/Library/Safari: operation not permitted
can not obtain extended attribute com.apple.metadata:com_apple_backup_excludeItem for /Users/me/Library/Suggestions:
error: Open: open /Users/me/Library/Suggestions: operation not permitted
can not obtain extended attribute com.apple.FinderInfo for /Users/me/Pictures/Photos Library.photoslibrary:
can not obtain extended attribute com.apple.quarantine for /Users/me/Pictures/Photos Library.photoslibrary:
error: Open: open /Users/me/Pictures/Photos Library.photoslibrary: operation not permitted

Files:         179 new,   261 changed, 857338 unmodified
Dirs:            0 new,     0 changed,     0 unmodified
Added to the repo: 266.392 MiB

processed 857778 files, 186.192 GiB in 12:57
snapshot 46831f24 saved
Thu Nov 15 02:12:58 MST 2018 :: restic-backup.sh finished.
Duration: 778 seconds

Nach der Behebung:

Tue Nov 27 02:00:00 MST 2018 :: Starting restic-backup.sh

Files:         389 new,  2367 changed, 1055845 unmodified
Dirs:            0 new,     0 changed,     0 unmodified
Added to the repo: 430.279 MiB

processed 1058601 files, 295.471 GiB in 18:16
snapshot e58d8f1c saved
Tue Nov 27 02:18:17 MST 2018 :: restic-backup.sh finished.
Duration: 1097 seconds

Derselbe Fix funktioniert auch auf dem Macbook Air meiner Frau, beide auf der Fernbedienung mit restic find '/Users/*/Library/Mail' --snapshot latest --host=$(hostname) verifiziert (wobei ~/Library/Mail eines der normalerweise geschützten Verzeichnisse ist, wie im obigen Fehlerprotokoll zu sehen ist) .

Ich bemerke insbesondere, dass stdout/stderr nach /dev/null verworfen wird. Es kann auch stdin nicht lesen, wenn beispielsweise restic nach einem Passwort fragen möchte.

Dies hängt ganz von Ihrem Skript ab. Wie Sie in meinem ursprünglichen Beitrag sehen können, ist mein Setup, da es vollständig automatisiert ist, so eingerichtet, dass es das Passwort aus einer (root-eigenen 0600-) Datei liest, aber es könnte auch aus einer envvar oder einer der üblichen Methoden lesen. Du hast Recht, ich glaube nicht, dass das für interaktive Sachen funktionieren wird. Es protokolliert auch alles in einer Datei: &>> /path/to/file.log .

(Auch irgendwie lustig, warum ist Ihre bash /usr/local/bin/bash und nicht /bin/bash? Nur neugierig.)

Ich benutze Homebrew , um eine neuere Version von bash zu bekommen

$ /bin/bash --version
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin18)
Copyright (C) 2007 Free Software Foundation, Inc.
$ /usr/local/bin/bash --version
GNU bash, version 4.4.23(1)-release (x86_64-apple-darwin17.5.0)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Dadurch bekomme ich modernere Funktionen, wie den Operator &>file.log (der im Vergleich zu 2>&1 >file.log einige Tastenanschläge einspart.

Bevor ich Ihren Blogbeitrag sah, war mein erster Instinkt, die Restic-Binärdatei selbst zur FDA hinzuzufügen, und das hat bei mir unter 10.14.1 (18B75) nicht funktioniert. Ich bin mir nicht sicher, warum das Einfügen eines anderen Programms (der Go-Wrapper, der ein Shell-Skript aufruft und letztendlich restic aufruft) etwas ändern würde.

Auch hier bin ich mir nicht ganz sicher. Für meinen Anwendungsfall habe ich viele andere Einstellungen, die ich in meinem Bash-Skript mache (ein etwas komplizierter sftp-Befehl, bei dem das Ziel, die Sicherungspfade und mehrere Optionen auf dem Hostnamen basieren), so dass das Aufrufen der Restic-Binärdatei selbst nicht der Fall war eine Option. Ich kann damit ein bisschen experimentieren.

Okay, danke für die Erklärung. Ich habe gerade versucht, neu zu erstellen, neu zu starten und FDA hinzuzufügen, und ich bekomme immer noch operation not permitted . Ich habe auch versucht, sowohl den Binär-Wrapper als auch das Shell-Skript in /Applications zu verschieben, und kein Glück. Ich werde weiter graben.

Hm. Muss definitiv nicht in /Applications für mich sein.

Bist du am 14.10. oder am 14.10.1? Ich bin bei letzterem.

Und Sie könnten versuchen, den tccutil-Befehl zu verwenden, auf den ich verwiesen habe, um alle Einträge vorher zu löschen.

Ich bin am 10.14.1 (18B75). Ich habe auch den Befehl tccutil ausprobiert, kein Glück. Ich verstehe, warum Apple das tut, aber es ist wirklich frustrierend, keinen klaren Weg zu haben, was hier zu tun ist.

Hm. Das ist komisch.

Seltsamerweise habe ich es versucht und kann die Restic-Binärdatei nicht direkt zum Laufen bringen.

Unklar, warum dies nicht funktioniert, aber mein Workaround ist (für mich).

Scheint ein weiterer intermittierender Fehler zu sein – ich denke, wir sollten abwarten
formelle Dokumentation / Aufschreiben, bis wir in der Lage sind, die von jemand anderem zu bekommen
Computer, der mit demselben System arbeitet. Ich bin 2 für 2, aber ich verstehe nicht warum
das funktioniert nicht für @armhold.

@armhold , können Sie eine Kopie des genauen Bash-Skripts und des Go-Codes posten, den Sie verwenden
verwenden und wie Sie es ausführen? Ich werde sehen, ob ich auf meiner Seite reproduzieren kann.

Seltsamerweise habe ich es versucht und kann die Restic-Binärdatei nicht direkt zum Laufen bringen.

Ja, das verstehe ich nicht. Ich verstehe nicht, warum der Go-Wrapper erfolgreich sein würde, wenn die Restic-Binärdatei selbst fehlschlagen würde. Irgendetwas scheint aus.

Können Sie eine Kopie des genauen Bash-Skripts und Go-Codes posten, den Sie verwenden, und wie Sie ihn ausführen?

Sicher, hier ist es: https://github.com/armhold/restic-fda.

• Sowohl das Shell-Skript als auch der Go-Wrapper sind in meinem ~/bin -Verzeichnis installiert.
• ~/bin/restic-fda über die Systemeinstellungen zu FDA hinzugefügt
• Ich führe restic-fda von einem Nicht-Root-Benutzerkonto interaktiv auf der Befehlszeile in Terminal aus. Ich erhalte Fehler wie: error: Open: open /Users/armhold/Library/Application Support/AddressBook: operation not permitted .
• Das Ausführen als root (über sudo) schlägt ähnlich fehl

Ich habe nicht versucht, es über launchctl auszuführen.

Little Snitch, eine Firewall, macht etwas Ähnliches - für ausgehende Verbindungen würde sie fragen, ob "Terminal via Restic" die Verbindung herstellen soll (anstatt nur Restic); dh Terminal.app ist die primäre App, der die Berechtigung erteilt werden muss.

Am Ende habe ich mein Shell-Skript als App mit Platypus gebündelt und dieser generierten App die FDA erteilt. Starten Sie dann Backups über den Finder. Funktioniert soweit.

launchctl wird der nächste Schritt sein.

Zu Ihrer Information, das funktioniert immer noch für mich (auch nach dem letzten MacOS
aktualisieren). Irgendwelche Neuigkeiten von @armhold?

Funktioniert bei mir immer noch nicht. Ich gab auf und gab nur Terminal FDA.

Leider bin ich wieder ratlos.

Ich bin am 14.10.2. Mein Restic-Backup-Skript funktioniert immer noch, keine Berechtigungsfehler in seinen Protokollen. Allerdings kann ich jetzt das Skript von @armhold oder sogar meine früheren Testskripte nicht zum Laufen bringen (die nichts anderes tun, als das geschützte Verzeichnis ~/Library/Mail zu öffnen).

🤷‍♂️

Haben Sie versucht, Ihren (funktionierenden) Wrapper auf einem neuen Repo auszuführen? Was ich meine ist, sind Sie sicher, dass keine Dateien übersprungen werden, die alt sind und daher bereits im Repo vorhanden sind? Ich kann mir vorstellen, dass Sie immer noch einen Fehler erhalten, wenn Sie versuchen, in die geschützten Ordner abzusteigen, während Restic den Baum durchläuft.

@mholt Wie ist der Status in Bezug auf dieses und Relikt - haben Sie es irgendwie umgangen, und wenn ja, können Sie uns mitteilen, welche Schritte Sie dazu unternehmen?

Nach dem Upgrade einiger Clients sehe ich dieses Verhalten auch, sehr ärgerlich und schwer zu handhaben, ohne Dinge einzupacken und herumzuspielen.

@rawtaz

Wie ist der Stand zu diesem Thema und dem Relikt – haben Sie es irgendwie umgangen, und wenn ja, können Sie uns mitteilen, welche Schritte Sie dazu unternehmen?

Ich selbst habe erst letzte Woche ein Upgrade auf Mojave durchgeführt. Aber ich habe Relica installiert und konnte den Fehler "Vorgang nicht zulässig" reproduzieren, als ich versuchte, ~/Library/Mail zu sichern.

Ich habe dann Relica.app zum FDA-Bildschirm hinzugefügt und das Relica-Backup erneut ausgeführt.

Es wurde diesmal erfolgreich ohne Fehler gesichert (während der erste Snapshot von Relica+restic den Mail-Ordner wegen des Berechtigungsfehlers überhaupt nicht anzeigte):

Ich fürchte, ich habe keine Antworten, die ich zu diesem Thread beitragen könnte. :-/ Ich bin mir nicht sicher, ob es _weiter_ funktioniert, aber ich hoffe natürlich, dass es funktioniert.

Ich habe mich auch dafür entschieden, mein Restic-Backup-Skript in ein .app-Bundle zu packen, um es FDA geben zu können. Es ist scheiße, das tun zu müssen, aber es scheint der einzig praktikable Weg nach vorne zu sein.

Zuerst habe ich versucht, nur die Restic-Binär-FDA zu geben, aber das hat nicht funktioniert.
Ich habe auch versucht, mein Backup-Skript (ein Bash-Skript, das Restic aufruft) FDA zu geben, aber das hat auch nicht funktioniert.
Ich habe den Wrapper von @armhold nicht ausprobiert.

Ich habe Platypus wie oben vorgeschlagen verwendet und es funktioniert großartig. Es erzeugt ein .app-Bundle, das ich dann der FDA in den Systemeinstellungen von macOS geben kann, und das löst das Problem.

Der einzige Nachteil, der mir während der Verwendung aufgefallen ist, ist, dass beim Start der .app (bei mir wird sie von crontab mit open -ga ~/Applications/Backup.app gestartet) das aktuelle Fenster den Fokus verliert. Dies kann für meine Benutzer ein ernsthaftes Ärgernis sein, ist es aber was es ist. Zumindest haben wir wieder funktionierende Backups. Ich dachte, der Schalter -g würde das erledigen, aber es ändert leider nichts.

Ich habe ganz kurz versucht zu sehen, was passiert, wenn Sie das .app-Bundle löschen (in den Papierkorb verschieben, Papierkorb leeren) und es durch ein neues .app-Bundle mit demselben Namen ersetzen. Meine Beobachtungen sind, dass beim Entfernen des alten der Eintrag in der FDA in den Systemeinstellungen verschwindet, aber wenn Sie den neuen an derselben Stelle wieder einfügen, erscheint der Eintrag erneut, was darauf hinweist, dass das System die neue .app erkennt und berücksichtigen würde FDA haben. Als ich danach die neue App ausführte, bekam ich jedoch die ursprünglichen Fehler zurück. Nachdem ich den FDA-Eintrag für die App in den Systemeinstellungen entfernt und einen neuen FDA-Eintrag dafür hinzugefügt hatte, waren die Fehler wieder weg. Im Moment gehe ich also davon aus, dass ich beim Ersetzen des .app-Bundles auch den FDA-Eintrag ersetzen muss, damit es funktioniert. Es kann sehr gut sein, dass, wenn man nur Teile des .app-Bundles ersetzt, es trotzdem weiter funktioniert. Dies bedarf weiterer Untersuchungen AFAICT.

Für alle, die restic in ein .app-Bundle bündeln möchten, hier ist ein etwas allgemeines Tutorial, das ich vor ein paar Monaten darüber geschrieben habe, wie man es für jedes Go-Programm macht, einschließlich des Codes, wenn Sie nur ein paar Einstellungen ändern und auf Ihrem sein möchten Weise: https://medium.com/@mattholt/packaging -a-go-application-for-macos-f7084b00f6b5

10.14.3 -- immer noch keine guten Nachrichten für die Ausführung nur mit Binärdateien.

$ /bin/ls ~/Library/Mail/
ls: : Operation not permitted

Funktioniert, wenn Terminal.app zu FDA hinzugefügt wird, aber nicht nur mit ls (oder anderen Binärdateien).

Applescript/Automator funktioniert, zeigt aber ein Symbol im Dock; Kompilieren Sie dies alternativ mit xcode/swift cli in eine Binärdatei und fügen Sie diese der FDA hinzu (ersetzen Sie /full/path/to durch Ihre echten Pfade).

import Foundation
import os

let task = Process()

task.launchPath = "/full/path/to/bash"
task.arguments = ["/full/path/to/backup_script.sh"]

do{
    try task.run()
}
catch{
    os_log("error")
}

task.waitUntilExit()

@daviehh kein Glück hier.

import Foundation
import os

let task = Process()

task.launchPath = "/bin/ls"
task.arguments = ["/Users/me/Library/Mail"]

do{
    try task.run()
}
catch{
    os_log("error")
}

task.waitUntilExit()

$ swiftc foo.swift
$ ./foo
ls: Mail: Operation not permitted
$ # add to FDA
$ ./foo
ls: Mail: Operation not permitted
$ sudo ./foo
ls: Mail: Operation not permitted

Ich habe vor kurzem angefangen, Restic zu verwenden, und habe versucht, es als Cron-Job zum Laufen zu bringen, der von der Root-Crontab sudo crontab -e aufgerufen wird, damit ich mich etwas sicherer fühlen kann, wenn ich mein Backup-Skript in einer Datei habe, auf die nur mit sudo-Berechtigungen zugegriffen werden kann . Ich habe genau die gleichen Fehler wie @n8henrie erhalten , aber jetzt habe ich eine funktionierende Lösung und würde gerne wissen, ob dies für andere hier funktioniert.

Erstmal ein kleiner Hintergrund zu meinem Setup:

Ich habe ein Backup-Skript in /Users/myuser/bin namens restic-backup.sh mit den Berechtigungen 700 (nur root/sudo read/write/execute). Ich führe diese Datei mit meinem root crontab sudo crontab -e aus. Ich verwende iTerm als mein Standardterminal. Ich habe restic und zsh mit Homebrew installiert.

macOS-Version 10.14.5

restic-backup.sh:

Meine Backup-Skriptdatei enthält Folgendes.

#!/usr/local/bin/zsh
restic_path="/usr/local/bin"
logFile="/Users/myuser/Documents/Backups/configurations/Mac/backup_logs/$(date +%F_%H%M)_restic.log"
unset HISTFILE
export RESTIC_REPOSITORY="..."
export AWS_ACCESS_KEY_I'd="..."
export AWS_SECRET_ACCESS_KEY="..."
export RESTIC_PASSWORD="..."
$restic_path/restic --verbose backup /Users/myuser  &> $logFile

Dann habe ich in meiner Root-Crontab-Datei: sudo crontab -e :

0 */2 * * * /Users/myuser/bin/restic-backup.sh

Bei vollem Festplattenzugriff:

cron ==> /usr/sbin/cron
iTerm.app ==> /Applications/iTerm.app

Wie bei @n8henrie dachte ich, dass die Programme, die tatsächlich auf die Dateien wie restic zugreifen, diejenigen wären, die die FDA benötigen, aber stattdessen scheint es, dass die Programme, die die anfängliche sudo -Anfrage stellen, die FDA benötigen: cron im automatisierten Fall und iTerm.app im manuellen Fall.

Ich habe etwas Nützliches entdeckt: Wenn eine App auf die Whitelist gesetzt wird, gilt dies für jedes Skript oder jede Binärdatei im Verzeichnis der App. Sie müssen die App also nicht direkt starten. Tatsächlich ist die App selbst völlig irrelevant – sie fungiert lediglich als Container für Whitelisting. Sie können Ihr Skript in eine beliebige App kopieren, diese App auf die Whitelist setzen und dann Ihr Skript ausführen. Die einzige Einschränkung ist, dass Sie die App jedes Mal entfernen und erneut zur Whitelist hinzufügen müssen, wenn Sie Ihr Skript oder Ihre Binärdatei darin ändern.

@atticusmatticus @russelldavis -- Ich denke, eines der letzten MacOS-Updates hat vielleicht wieder etwas geändert -- ich hatte definitiv beide Strategien ohne Glück ausprobiert. Aber ich hatte auch Folgendes versucht, das nicht mehr funktionierte, aber jetzt wieder funktioniert (irgendwie):

package main

import (
    "fmt"
    "io/ioutil"
)

func main() {
    fmt.Println("Starting...")
    matches, err := ioutil.ReadDir("/Users/me/Library/Mail")
    if err != nil {
        fmt.Println("Err:", err)
    } else {
        for _, match := range matches {
            fmt.Println(match.Name())
        }
    }
}

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
    <dict>
        <key>Label</key>
        <string>com.me.gotest</string>
        <key>ProgramArguments</key>
        <array>
            <string>/Users/me/go/src/github.com/me/gotest/gotest</string>
        </array>
        <key>StartInterval</key>
        <integer>15</integer>
        <key>StandardErrorPath</key>
        <string>/Users/me/go/src/github.com/me/gotest/stderr.txt</string>
        <key>StandardOutPath</key>
        <string>/Users/me/go/src/github.com/me/gotest/stdout.txt</string>
    </dict>
</plist>

1. go build
2. Fügen Sie die Binärdatei gotest (und sonst nichts) zu Full Disk Access hinzu
3. Kopieren Sie die Plist nach ~/Library/LaunchAgents/
4. Laden Sie den launchd-Daemon: launchctl load -w ~/Library/LaunchAgents/com.me.gotest.plist

Jetzt, seltsamerweise, mit der gotest -Binärdatei, aber nicht launchd (oder launchctl ), die der FDA hinzugefügt wurde, kann ich immer noch nicht direkt ausführen:

$ ls -l gotest
-rwxr-xr-x 1 me staff 2142552 Jul  2 09:15 gotest
$ ./gotest
Starting...
Err: open /Users/me/Library/Mail: operation not permitted
$ sudo ./gotest
Password:
Starting...
Err: open /Users/me/Library/Mail: operation not permitted

Aber es läuft ohne Fehler vom launchd-Daemon (alle 15 Sekunden wie konfiguriert), der nicht als Root läuft ( ~/Library/ nicht /Library/ , und launchctl load nicht sudo launchctl load ):

$ cat stdout.txt | head
Starting...
.DS_Store
PersistenceInfo.plist
V6
Starting...
.DS_Store
PersistenceInfo.plist
V6
Starting...
.DS_Store

Seltsamerweise sehe ich immer noch, einschließlich eines Neustarts:

||gehe binär in FDA|gehe binär nicht in FDA
---|:---:|:---:
gehe binär ohne sudo |err|err
gehe binär mit sudo |err|err
launchd läuft binär|RUNS|err

Nicht direkt mit Restic verbunden, aber mit dem FDA-Problem.
Ich glaube, ich habe eine Ahnung, wie es wohl funktioniert, und ich hoffe, ich bin nicht offensichtlich Kapitän gewesen. Ich habe noch keine hilfreiche Diskussion, Artikel oder Dokumentation darüber gefunden.

Die FDA arbeitet für Anwendungen, die auf der Whitelist stehen (Öffnen bedeutet, dass sie von launchd gestartet werden), für alle untergeordneten Prozesse dieser Anwendungen, auch nicht auf der Whitelist, und für Binärdateien auf der Whitelist, wenn sie direkt von launchd ( launchd.plist oder launchctl submit ). Es funktioniert nicht, wenn eine Whitelist-Binärdatei in einem Prozessbaum mit einer nicht auf der Whitelist befindlichen übergeordneten Anwendung/Binärdatei gestartet wird.

Daraus sieht es so aus, als ob launchd für das Whitelisting des Prozessbaums verantwortlich ist, je nachdem, welche Anwendung/Binärdatei auf die Whitelist gesetzt wurde.

Aus Experimenten sieht es so aus, als ob der Pfad zur Binärdatei genau sein sollte, so dass Whitelisting nicht ausgelöst wird, wenn für die Whitelist-Binärdatei launchctl plist WorkingDirectory angegeben ist und der relative Pfad ./some-binary verwendet wird, es wird nicht einmal funktionieren für /some/path/./some-binary oder /some/path/../path/some-binary nur /some/path/some-binary .
Es ist auch nicht möglich, eine Whitelist-Anwendung für Shebang zu verwenden, selbst wenn das Skript direkt von launchd gestartet wird, also funktioniert #!/some/path/some-binary nicht, nur /some/path/some-binary /path/to/script .

Ja, ich laufe von launchd . Einige interessante Lektüre hier

https://eclecticlight.co/2018/10/02/how-privacy-protection-is-enforced-through-the-attribution-chain/

https://eclecticlight.co/2018/09/06/working-with-mojaves-privacy-protection/

Ich denke, wir haben genug Informationen und Datenpunkte, um zumindest einige Richtlinien (und vielleicht einen Link zu diesem Problem) in den Dokumenten bereitzustellen, und ich würde gerne damit beginnen, daran zu arbeiten, wenn das in Ordnung ist.

Sollte dies ein neuer Punkt unter Beispiele sein, wie der Abschnitt über das Sichern ohne Ausführung als root unter Linux ?

Ich plane Folgendes anzumerken:

• Vollständiger Festplattenzugriff ist erforderlich, um so viel wie möglich von der Festplatte zu sichern
• Ein launchd-Skript, das als root ausgeführt wird, kann eine Binärdatei aufrufen, die auf der Whitelist der FDA steht, ohne dass launchd zur FDA hinzugefügt werden muss
• Sofern Terminal.app nicht in der FDA aufgeführt ist, kann die Binärdatei nicht auf die gesamte Festplatte zugreifen, wenn sie von Terminal aufgerufen wird
• Wenn Terminal.app in der FDA aufgeführt ist, kann es auf die gesamte Festplatte zugreifen, wenn es eine Binärdatei aufruft, unabhängig davon, ob diese Binärdatei in der FDA ist oder nicht

Klingt das so, als würde es das Verständnis und die Erfahrung aller widerspiegeln?

Obwohl etwas kompliziert, war ich zufrieden mit meinem Setup, das in den letzten > 1 Jahr auf 2 Macbooks lief, und ich würde wahrscheinlich Teile davon als Beispiel hinzufügen. Mein Setup ist:

• Ich habe ein Shell-Skript, das einen maschinenspezifischen Restic-Befehl basierend auf verschiedenen Umgebungsvariablen ausführt (dasselbe Skript läuft auch auf 4 Linux-Computern, die dieses Skript direkt aufrufen).
• Auf meinen MacOS-Computern baue ich eine Go-Binärdatei, die im Grunde nur das obige Shell-Skript ausführt. Ich verwende hier ein Shell-Skript zur einfachen Konfiguration / Updates / Versionskontrolle, obwohl dies auch direkt in Go problemlos möglich wäre.
• Diese Binärdatei wird der FDA hinzugefügt
• Ich führe einen systemweiten Launchd-Daemon aus (der mit Root-Berechtigungen ausgeführt wird), um diese Go-Binärdatei nach einem Zeitplan zu starten

Die Verwendung einer Binärdatei ähnlich https://github.com/restic/restic/issues/2051#issuecomment -442872479 funktioniert für mich. Ich ging mit c, da ich go gerade nicht installiert habe. Für andere zum Kopieren/Einfügen:

1. backup.c

#include <stdlib.h>
int main(void) {
  int status = system("./backup.sh");
  int ret = WEXITSTATUS(status);
  return ret;
}

1. kompilieren: gcc -Wall -o backup backup.c
2. die Backup-Binärdatei auf die Whitelist setzen und nach Belieben verwenden

Seltsamerweise sehe ich immer noch, einschließlich eines Neustarts:

gehe binär in FDA gehe binär nicht in FDA
gehe binär ohne sudo err err
gehe binär mit sudo err err
launchd läuft binär RUNS err

Danke!

Die Lösung für mich bestand darin, eine .plist-Datei zu erstellen, die restic direkt aufruft und alle Parameter entweder innerhalb oder in separaten Dateien ablegt, wobei die Optionen -p, --exclude-files, --files-from verwendet werden. Und natürlich geben Sie restic binäre FDA-Berechtigungen:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>my.backup_agent</string>

    <key>ProgramArguments</key>
    <array>
        <string>/usr/local/bin/restic</string>
        <string>backup</string>

        <string>-r</string>
        <string>s3:https://MY.STORAGE.SERVER/....</string>

        <string>-p</string>
        <string>.config/backup/restic.pwd</string>

        <string>--files-from</string>
        <string>.config/backup/backup.lst</string>

        <string>--exclude-file</string>
        <string>.config/backup/exclude.lst</string>
    </array>

    <key>EnvironmentVariables</key>
    <dict>
        <key>AWS_ACCESS_KEY_ID</key>
        <string>XXX</string>

        <key>AWS_SECRET_ACCESS_KEY</key>
        <string>YYY</string>
    </dict>

    <key>WorkingDirectory</key>
    <string>/Users/ME</string>

    <key>StandardErrorPath</key>
    <string>/Users/ME/log/backup.log</string>

    <key>StandardOutPath</key>
    <string>/Users/ME/log/backup.log</string>

    <key>StartCalendarInterval</key>
    <dict>
        <key>Hour</key>
        <integer>13</integer>

        <key>Weekday</key>
        <array>
        <integer>1</integer>
        <integer>2</integer>
        <integer>3</integer>
        <integer>4</integer>
        <integer>5</integer>
        </array>
    </dict>
</dict>
</plist>

Wie finde ich heraus, welche App zur FDA hinzugefügt werden sollte? Kurz gesagt, finden Sie, dass die App ausgeführt wird.

Sie können den Prozess am Laufen halten und die übergeordnete PID des Prozesses durchlaufen, bis die Vorfahren-PID 1 ist, starten Sie über ps ajx oder ps ao pid,ppid,command mit grep .

Und kurz:

• Ausführung über crontab, /usr/sbin/cron , veraltet von launchd.plist
• Ausführen über launchd.plist, die Binärdatei in Program oder ProgramArguments
• laufen in Terminal, Terminal.app
• laufen über ssh, /usr/libexec/sshd-keygen-wrapper oder ähnliches
• über andere App ausführen, finden.

Für @n8henrie müssen Sie also die eigentliche Binärdatei finden.

Eine andere Möglichkeit, dies zu beheben, wenn Sie Dinge über launchd ausführen: LaunchControl wird jetzt mit einem Helfer namens fdautil ausgeliefert, den Sie auf die Whitelist setzen und dann Befehle mit fdautil exec ausführen können. Es werden nur Befehle zugelassen, die Sie über LaunchControl oder fdautil set die Whitelist gesetzt haben.

Es gibt ein paar Informationen darüber unter https://www.soma-zone.com/LaunchControl/FAQ.html und weitere Details im Hilfefenster der App.