Restic: MacOS Mojave : erreur : Ouvrir : ... opération non autorisée

Ouais, apparemment, vous devez faire le truc d'accès complet au disque : https://www.backblaze.com/blog/mojave-permissions/

Êtes-vous _sûr_ d'avoir ajouté le bon binaire restic ? Avez-vous déplacé le fichier ou modifié l'un de ses attributs (propriété, etc.) après l'avoir ajouté à l'accès complet au disque dans les Préférences Système ?

(J'ai un Mac, mais je n'ai pas encore Mojave, désolé.)

J'utilise homebrew, donc j'ai d'abord ajouté /usr/local/bin/restic à Full Disk Access, commencé un travail, noté les mêmes erreurs, puis j'ai supprimé cela et ajouté le chemin vers le binaire réel (en notant que cela devrait malheureusement être refait à chaque mise à jour restic): /usr/local/Cellar/restic/0.9.2/bin/restic , malheureusement je vois les mêmes erreurs.

Aucun changement, ajout d'un binaire à l'accès complet au disque, retour au terminal et exécution sudo myscript.sh , qui fonctionnait pour la plupart des fichiers mais donnait des erreurs d'autorisation sur d'autres.

Remarque complémentaire, il y a un autre problème (peut-être lié à Mojave) que j'essaie d'étoffer, où mon authentification sftp pubkey a cessé de fonctionner lorsqu'elle est exécutée à partir de launchctl (en tant que root), mais fonctionne lorsqu'elle est exécutée manuellement en tant que root, mais je vais déposer un nouveau problème si je suis en mesure de déterminer qu'il n'est pas spécifique à ma configuration.

Intéressant. Que se passe-t-il si vous lancez restic directement ? Et/ou ajoutez votre script à la FDA. Juste tirer dans le noir ici, honnêtement. Si j'avais Mojave, je l'essayerais.

Bonne pensée.

Mon script lui-même n'est pas exécutable (sans raison valable), comme indiqué, je l'exécute avec sudo bash myscript.sh ( /usr/local/bin/bash en fait); il ne peut pas être ajouté à FDA car il n'est pas exécutable.

J'ai essayé d'ajouter /usr/local/bin/bash à la FDA et pas de dés.

EDIT: je me trompe apparemment, même après chmod +x , mes backup.sh ne peuvent toujours pas être ajoutés directement à la FDA (alors que les binaires bash et restic pouvez). Impair.

EDIT2 : Juste pour être complet, j'ai ajouté les binaires bash et restic à la FDA et je vois la même erreur.

Probablement un problème plus important que restic - j'ai même essayé d'ajouter /bin/ls à la liste de la FDA et j'obtiens toujours une erreur.

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

EDIT : Solution de contournement laide : ajoutez Terminal.app aux autorisations de la FDA et les erreurs d'autorisation disparaissent.

Fil de discussion pertinent : https://forums.developer.apple.com/thread/107546

J'ai essayé codesign à la fois le binaire restic et mon script backup.sh et ajouté à la FDA, pas de chance.

(Après avoir lu une partie de ce fil) Mon Dieu. C'est super ennuyeux. Merci de l'avoir examiné ! Je continuerai à enquêter aussi une fois que j'aurai mis à jour...

Wow, merci beaucoup pour l'information et tout le temps que vous avez passé sur le problème! Je n'ai pas du tout de mac, donc je suis content si vous pouviez tous les deux le comprendre et nous pouvons documenter ce problème pour les autres utilisateurs ! Merci encore!

@mholt Si vous le souhaitez, vous pouvez installer une version d'essai de 30 jours de VMware Fusion et y installer Mojave (à moins qu'Apple n'ait paralysé la possibilité de l'installer ad hoc). Cette version d'essai ne cause aucune pollution et peut être désinstallée si vous ne le souhaitez pas plus tard.

J'ai noté ci-dessus que l'ajout Terminal.app à la liste System Preferences -> Security & Privacy -> Full Disk Access était une solution de contournement, car lorsque j'ai exécuté manuellement mon script ( sudo /usr/local/bin/bash mybackup.sh ) cela semblait fonctionner sans les erreurs d'autorisations.

Pour une raison quelconque, lorsque j'ai vérifié mes journaux ce matin à partir de l'exécution automatisée du restic pendant la nuit (basée sur un script launchd à /Library/LaunchDaemons/com.n8henrie.restic.plist qui s'exécute la nuit avec les privilèges root), les erreurs d'autorisations sont toujours là.

Et malheureusement, je ne parviens plus à faire fonctionner la solution de contournement - même avec Terminal.app en FDA, j'obtiens toujours les erreurs d'autorisation lorsque j'exécute sudo launchctl start com.n8henrie.restic ou sudo /usr/local/bin/bash mybackup.sh .

La solution de contournement ne semble donc pas fonctionner ou quelque chose a changé.

EDIT : Gah, je viens d'ajouter les 3 à la FDA - Terminal.app , /usr/local/bin/bash et /usr/local/Cellar/restic/0.9.2/bin/restic - et maintenant, il a fonctionné sans erreur. 🤷‍♂️

FWIW, voici ma sortie de journal , qui contient la liste des fichiers obtenant des erreurs. Comme vous pouvez le voir, il y a de gros soucis, comme ma photothèque.

@n8henrie D'après le fil de support Mac auquel vous avez lié plus tôt, il semble que la FDA exige que les applications approuvées soient un ensemble .app enregistré dans le dossier Applications, ce qui pourrait expliquer pourquoi Terminal.app réussit ... mais vous devez ajouter les 3 à la FDA dans votre cas ? Intéressant...

@mholt , il semble que quelque chose d'autre se passe. J'ai laissé mes paramètres exactement tels qu'ils étaient hier (tous les 3 dans la FDA, qui n'ont produit aucune erreur d'autorisation), et mon exécution nocturne a toujours les mêmes anciennes erreurs d'autorisation.

Cela s'est produit deux fois maintenant, où après avoir bricolé pendant un certain temps, j'obtiens des exécutions sans erreurs d'autorisations qui réapparaissent ensuite. Restic sait-il d'une manière ou d'une autre si un fichier a changé ou non sans avoir besoin d'ouvrir le fichier - une sorte de cache? Je me demande si je me fais berner par des exécutions rapprochées, et qu'il n'y a pas eu de modifications intermédiaires dans un fichier et que, par conséquent, restic n'essaie pas de l'ouvrir?

Sinon, j'ai du mal à expliquer ce qui se passe ici.

Bonne question. Je sais que restic utilise un cache mais je n'ai pas examiné avec quelle agressivité il y adhère en cas d'erreurs d'autorisations, etc.

Discussion pertinente sur SO : https://apple.stackexchange.com/q/338213/27415

Bonne question. Je sais que restic utilise un cache mais je n'ai pas examiné avec quelle agressivité il y adhère en cas d'erreurs d'autorisations, etc.

Pas du tout. Le cache ne contient que des fichiers du référentiel, aucune information sur le système de fichiers (qui ne se trouve pas dans le référentiel) n'est incluse.

D'accord - ouais, je ne pense pas que ce soit un bogue dans restic. Il s'agit définitivement d'un problème macOS Mojave que, à ce stade, je suis à peu près sûr que le restic lui-même ne peut rien faire pour le résoudre.

Cool, merci pour le retour, je ferme ce sujet pour l'instant. S'il vous plaît ajouter plus de commentaires si vous découvrez des choses. Merci!

Je suis un peu surpris de voir que le problème est déjà clos - cela ressemble à un
incompatibilité majeure avec une plate-forme majeure, et la fermer à ce stade
peut le mettre "loin des yeux, loin du coeur".

Je comprends que ce n'est pas principalement un problème de restriction, mais il semble que
certaines mesures raisonnables peuvent être prises pour les utilisateurs de MacOS. Comme si,
la capacité d'un utilisateur à sauvegarder une grande partie de ses données personnelles les plus importantes
les données (par exemple les photos) sont compromises par défaut sur la version actuelle de
MacOS. Cela me semble être un gros problème, pour tout logiciel de sauvegarde !

Quelques suggestions / possibilités (sur lesquelles je suis heureux d'aider à travailler):

• Possibilités de résolution du problème
  
  
  
  • Est-il possible de fournir une application wrapper MacOS appropriée qui
    
    peut être ajouté à la liste de la FDA, qui contient le binaire restic
  
  
  • Si vous savez comment faire ce qui précède, au lieu de fournir le
    
    application, pourrions-nous inclure des instructions sur la façon dont les utilisateurs peuvent l'accomplir
    
    eux-mêmes avec une sorte de Makefile ou XCode ?
  
  
• Solutions de contournement
  
  
  
  • Fournissez des informations dans la documentation concernant les binaires les plus sécurisés/minimaux
    
    qui doivent être ajoutés à la FDA
  
  
  • Fournir des liens vers des informations concernant (et les risques de) la désactivation de SIP
  
  
• Mises en garde
  
  
  
  • Inclure des informations dans les documents quelque part que les utilisateurs de Mojave n'auront pas
    
    leurs données entièrement sauvegardées par défaut
  
  

Dans l'ensemble, la situation ne semble pas très différente d' une sauvegarde complète sans racine
sous Linux, la désactivation complète de SIP étant quelque chose comme courir en tant que
racine, et déterminer et recommander un compromis raisonnablement sûr avec
FDA étant quelque chose comme utiliser setcap .

Malheureusement, mon Macbook est dans la boutique cette semaine donc je ne pourrai pas
travailler sur l'un de ces tout de suite, mais je serais intéressé d'entendre des pensées
des autres; peut-être que je suis loin de la base, ou peut-être que j'ignore les détails de
le flux de travail de l'équipe restic pour la gestion des problèmes.

Quelques mises à jour supplémentaires maintenant que j'ai récupéré ma machine :

Je ne peux pas reproduire mes succès ci-dessus pour obtenir une sauvegarde complète du système à partir de mon script launchd.

J'ai essayé d'ajouter tous les éléments ci-dessous à la liste de la FDA (en même temps) et j'obtiens toujours les erreurs :

• restique
• frapper
• lancerctl
• lancé
• Terminal.app

Juste pour l'expérimentation, les binaires nus semblent bien fonctionner lorsqu'ils sont ajoutés à la liste de la FDA et semblent n'avoir rien à voir avec le codesigning. Comparez les binaires ls fournis par MacOS et par Homebrew :

$ 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

Avant et en ajoutant à la liste FDA :

$ /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

De plus, ils fonctionnent bien lorsqu'ils sont placés dans un script bash tant que ls est dans la FDA (pas besoin d'ajouter bash séparément), ce qui me fait penser que je devrais seulement ajouter restic .

En outre, à titre de comparaison, exécutez les erreurs de script Go suivantes si elles ne sont pas dans FDA, mais fonctionnent bien par elles-mêmes ainsi que lorsqu'elles sont appelées depuis launchd tant que le binaire est dans FDA (inutile d'ajouter launchd / launchctl / quoi que ce soit d'autre).

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())
        }
    }
}

Sortir:

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

Ensuite, je ferai quelques expériences avec Restic pour voir si je peux comprendre pourquoi il obtient des erreurs d'autorisation même lorsqu'il est ajouté à la FDA (bien que d'autres binaires semblent fonctionner une fois ajoutés).

D'accord, merci pour les commentaires ! Je vais rouvrir ce problème, peut-être que nous pourrons comprendre ce qui se passe, puis ajouter de la documentation au manuel.

~ J'obtiens toujours des erreurs de Open sur un nouveau dépôt, avec restic ajouté à la liste de la FDA.~

Voir la modification ci-dessous.

$ 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

EDIT : ne tenez pas compte de ce commentaire - je suis toujours en proie à des erreurs intermittentes qui entravent tout progrès, peut-être en association avec la mise à jour vers MacOS 10.14.1 hier. Aujourd'hui, le même code Go d'hier qui a toujours fonctionné avec la FDA et a échoué sans lui (je l'ai activé et désactivé plusieurs fois pour être sûr) ne fonctionne plus même avec la FDA . Idem avec ls .

Cela fonctionne si Terminal.app est ajouté à FDA (comme entrée unique), ce qui n'était pas nécessaire hier.

🤷‍♂️

Je reviendrai si je peux trouver quelque chose à ce sujet dans les forums Apple.

EDIT2 : le Macbook de Wife est toujours sur 10.14, et /bin/ls ~/Library/Mail ne fonctionne pas avec /bin/ls ajouté à la FDA, il semble donc que ce ne soit pas quelque chose de nouveau dans 10.14.1. 😕

Je travaille toujours là-dessus.

Cela continue d'être assez douloureux, mais j'ai enfin une solution de contournement qui, je pense, fonctionnera pour mes besoins.

J'ai détaillé le processus ici , mais l'essentiel est:

Vous pouvez utiliser Script Editor.app pour transformer un AppleScript en un ensemble d'applications. Cet AppleScript peut exécuter votre script de sauvegarde restic (dans mon cas /path/to/restic-backup.sh , où restic-backup.sh est un script bash qui s'exécute restic avec les paramètres souhaités), et vous pouvez ajouter le bundle d'applications résultant à FDA dans afin d'accéder aux fichiers protégés.

Cependant, cela rend difficile l'automatisation de l'exécution des sauvegardes au niveau du système. La commande intégrée open fonctionne, mais exécute l'application sous votre utilisateur - ainsi, pendant que les fichiers protégés par la FDA ci-dessus sont sauvegardés, vous obtiendrez des erreurs d'autorisations sur tous les fichiers qui ne sont lisibles que par root (par exemple root -possédé 0600 trucs).

Ma solution de contournement à ce stade consiste à demander à AppleScript d'appeler le script de sauvegarde avec sudo et de donner à mes privilèges d'utilisateur l'exécution de ce script avec les privilèges root sans mot de passe ( sudo visudo , NOPASSWD: , etc.).

Ce n'est pas joli, mais ça a l'air de fonctionner.

J'aimerais laisser cela ouvert à toute suggestion d'utilisateurs de MacOS ayant plus d'expertise. Si rien de plus satisfaisant ne se présente, je pourrais ajouter cette information à la documentation (bien que cette solution ne semble honnêtement pas très satisfaisante).

Incroyable, cela semble fonctionner et est beaucoup plus propre et plus simple.

// 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)
    }
}

Le binaire résultant peut être chown root et chmod 0700 , puis ajouté à Full Disk Access, et cela semble fonctionner. Il peut ensuite être ajouté à un plist /Library/LaunchDaemons pour s'exécuter automatiquement.

Les 2 premiers runs fonctionnent jusqu'à présent, j'espère que cela ne se terminera pas comme plusieurs faux départs ci-dessus.

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

Ma course automatisée hier soir a fonctionné. Je déploie cette stratégie sur le Macbook Air de ma femme aujourd'hui, s'il semble que cela fonctionne également là-bas, je considérerai cela comme une solution raisonnable et travaillerai sur un petit PR à https://github.com/restic/restic. net (si cela semble raisonnable).

Salut @n8henrie , je suis venu ici après avoir rencontré ce problème précis, puis trouvé votre article de blog. Merci d'avoir fait toutes ces recherches.

La solution ci-dessus (appeler le script shell à partir d'un simple binaire Go) ne fonctionne pas pour moi. Êtes-vous sûr qu'il accède avec succès à tous vos fichiers ?

Je remarque en particulier que stdout/stderr est supprimé de /dev/null. Il ne peut pas non plus lire stdin si, par exemple, restic veut demander un mot de passe. (Aussi assez drôle, pourquoi votre bash est-il /usr/local/bin/bash et non /bin/bash ? Juste curieux.)

Quoi qu'il en soit, j'ai apporté les modifications suivantes pour voir la sortie d'erreur :

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

Avant de voir votre article de blog, mon premier réflexe a été d'ajouter le binaire restic lui-même à la FDA, et cela n'a pas fonctionné pour moi sous 10.14.1 (18B75). Je ne sais pas pourquoi l'insertion d'un autre programme (le wrapper Go appelant un script shell, appelant finalement restic) changerait quoi que ce soit.

Cela fonctionne-t-il toujours pour vous ?

@n8henrie merci de nous tenir au courant ! Vous pouvez également écrire un article de blog à ce sujet sur le blog restic si vous êtes partant (en plus d'une petite section dans le manuel ou autre)... :)

@fd0 je serais honoré !

@armhold oui, semble fonctionner comme un charme, voir ci-dessous. Sur le MBA de ma femme, je pense que j'avais besoin d'un redémarrage avant qu'il ne commence à fonctionner (pas sur le mien cependant). IIRC pour le sien, j'ai créé le binaire, puis redémarré, puis ajouté à la FDA, et cela a fonctionné.

Avant le correctif :

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

Après le correctif :

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

Le même correctif fonctionne également sur le Macbook Air de ma femme, tous deux vérifiés sur la télécommande avec restic find '/Users/*/Library/Mail' --snapshot latest --host=$(hostname) (où ~/Library/Mail est l'un des répertoires généralement protégés, comme on peut le voir dans le journal des erreurs ci-dessus) .

Je remarque en particulier que stdout/stderr est supprimé de /dev/null. Il ne peut pas non plus lire stdin si, par exemple, restic veut demander un mot de passe.

Cela dépendra entièrement de votre script. Comme vous pouvez le voir dans mon message d'origine, puisque ma configuration est entièrement automatisée, elle est configurée pour lire le mot de passe à partir d'un fichier (0600 appartenant à la racine), mais peut également lire à partir d'un envvar ou de l'une des méthodes habituelles. Vous avez raison, je ne pense pas que cela fonctionnera pour les trucs interactifs. Il enregistre également tout dans un fichier : &>> /path/to/file.log .

(Aussi amusant, pourquoi votre bash est-il /usr/local/bin/bash et non /bin/bash ? Juste curieux.)

J'utilise Homebrew pour obtenir une version plus récente de bash

$ /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.

Cela me donne des fonctionnalités plus modernes, telles que l'opérateur &>file.log (qui économise quelques frappes par rapport à 2>&1 >file.log .

Avant de voir votre article de blog, mon premier réflexe a été d'ajouter le binaire restic lui-même à la FDA, et cela n'a pas fonctionné pour moi sous 10.14.1 (18B75). Je ne sais pas pourquoi l'insertion d'un autre programme (le wrapper Go appelant un script shell, appelant finalement restic) changerait quoi que ce soit.

Je ne suis pas non plus tout à fait sûr de cela. Pour mon cas d'utilisation, j'ai beaucoup d'autres configurations que je fais dans mon script bash (commande sftp quelque peu compliquée où la destination, les chemins de sauvegarde et plusieurs options sont basés sur le nom d'hôte) donc appeler le binaire restic lui-même n'était pas une option. Je peux expérimenter un peu.

D'accord, merci pour l'explication. Je viens d'essayer de reconstruire, de redémarrer + d'ajouter FDA, et j'obtiens toujours operation not permitted . J'ai également essayé de déplacer à la fois le wrapper binaire et le script shell dans /Applications, sans succès. Je vais continuer à creuser.

Hein. Certainement pas besoin d'être dans /Applications pour moi.

Êtes-vous sur 10.14 ou 10.14.1 ? Je suis sur ce dernier.

Et vous pouvez essayer d'utiliser la commande tccutil que j'ai référencée pour effacer toutes les entrées au préalable.

Je suis sur 10.14.1 (18B75). J'ai aussi essayé la commande tccutil, pas de chance. Je comprends pourquoi Apple fait cela, mais c'est vraiment frustrant de ne pas avoir une idée claire de ce qu'il faut faire ici.

Hein. C'est étrange.

Bizarrement, j'ai essayé et je n'arrive pas à faire fonctionner directement le binaire restic.

Je ne sais pas pourquoi cela ne fonctionne pas, mais ma solution de contournement est (pour moi).

Cela ressemble à une autre erreur intermittente - je pense que nous devrions attendre
documentation formelle / rédaction jusqu'à ce que nous soyons en mesure d'obtenir celle de quelqu'un d'autre
ordinateur fonctionnant avec le même système. Je suis 2 pour 2, mais je ne vois pas pourquoi
cela ne fonctionne pas pour @armhold.

@armhold , pouvez-vous poster une copie du script bash exact et du code Go que vous utilisez
à l'aide et comment vous l'exécutez? Je vais voir si je peux reproduire de mon côté.

Bizarrement, j'ai essayé et je n'arrive pas à faire fonctionner directement le binaire restic.

Oui, c'est ce que je ne comprends pas. Je ne vois pas pourquoi le wrapper Go réussirait là où le binaire restic lui-même échouerait. Quelque chose ne va pas.

pouvez-vous publier une copie du script bash exact et du code Go que vous utilisez et comment vous l'exécutez ?

Bien sûr, le voici : https://github.com/armhold/restic-fda.

• le script shell et le wrapper go sont installés dans mon répertoire ~/bin .
• ajouté ~/bin/restic-fda à la FDA via les Préférences Système
• J'exécute restic-fda partir d'un compte d'utilisateur non root de manière interactive sur la ligne de commande dans Terminal. J'obtiens des erreurs comme : error: Open: open /Users/armhold/Library/Application Support/AddressBook: operation not permitted .
• l'exécution en tant que root (via sudo) échoue de la même manière

Je n'ai pas essayé de l'exécuter via launchctl.

Little Snitch, un pare-feu, fait quelque chose de similaire - pour les connexions sortantes, il demanderait s'il faut autoriser "Terminal via restic" à établir la connexion (plutôt que simplement restic); c'est-à-dire que Terminal.app est le principal auquel accorder l'autorisation.

Ce que j'ai fait à la fin, c'est de regrouper mon script shell en tant qu'application utilisant Platypus et d'accorder FDA à cette application générée. Lancez ensuite les sauvegardes via le Finder. Fonctionne jusqu'à présent.

launchctl sera la prochaine étape.

Pour votre information, cela fonctionne toujours pour moi (y compris après le dernier MacOS
mettre à jour). Des nouvelles de @armhold ?

Ne fonctionne toujours pas pour moi. J'ai abandonné et j'ai juste donné Terminal FDA.

Malheureusement, je suis de nouveau bloqué.

Je suis sur 10.14.2. Mon script de sauvegarde restic fonctionne toujours, aucune erreur d'autorisation dans ses journaux. Cependant, je ne peux plus faire fonctionner le script de @armhold ni même mes scripts de test précédents (qui ne font rien d'autre qu'ouvrir le répertoire protégé ~/Library/Mail ).

🤷‍♂️

Avez-vous essayé d'exécuter votre wrapper (de travail) sur un nouveau dépôt ? Ce que je veux dire, c'est que vous êtes sûr qu'il n'ignore pas les fichiers anciens et donc déjà présents dans le dépôt ? J'imagine que vous auriez toujours une erreur en essayant de descendre dans les dossiers protégés, car restic parcourt l'arbre.

@mholt Quel est le statut de cela et de la relica - avez-vous travaillé autour d'une manière ou d'une autre, et si oui, pouvez-vous partager avec nous les mesures que vous prenez pour le faire ?

Après avoir mis à niveau quelques clients, je constate également ce comportement, très ennuyeux et difficile à gérer sans emballer des choses et déconner.

@rawtaz

Quel est le statut de cela et de la relica - avez-vous travaillé autour d'une manière ou d'une autre, et si oui, pouvez-vous partager avec nous les mesures que vous prenez pour le faire ?

Je ne suis moi-même passé à Mojave que la semaine dernière. Mais j'ai installé Relica et j'ai pu reproduire l'erreur "opération non autorisée" lors de la tentative de sauvegarde ~/Library/Mail.

J'ai ensuite ajouté Relica.app à l'écran FDA et réexécuté la sauvegarde Relica.

Il a été sauvegardé avec succès sans erreur cette fois (alors que le premier instantané réalisé par Relica+restic n'affichait pas du tout le dossier Mail à cause de l'erreur d'autorisation) :

Je crains donc de ne pas avoir de réponses pour contribuer à ce fil. :-/ Je ne sais pas si ça va _continuer_ à fonctionner mais bien sûr j'espère que ça marche.

Moi aussi, j'ai décidé d'envelopper mon script de sauvegarde restic dans un bundle .app pour pouvoir le donner à la FDA. C'est nul d'avoir à le faire, mais cela semble être le seul moyen pratique d'avancer.

Au début, j'ai essayé de ne donner que le binaire restic FDA, mais cela n'a pas fonctionné.
J'ai également essayé de donner mon script de sauvegarde (un script Bash qui appelle restic) FDA, mais cela n'a pas fonctionné non plus.
Je n'ai pas essayé l'emballage de @armhold .

J'ai utilisé Platypus comme suggéré ci-dessus, et cela fonctionne très bien. Il produit un ensemble .app que je peux ensuite donner à la FDA dans les paramètres système de macOS, et cela résout le problème.

Le seul inconvénient que j'ai remarqué lors de l'utilisation est que lorsque le .app démarre (pour moi, il est démarré par crontab en utilisant open -ga ~/Applications/Backup.app , la fenêtre actuelle perd le focus. Cela peut être une gêne sérieuse pour mes utilisateurs, mais c'est ce que c'est. Au moins, nous avons à nouveau des sauvegardes fonctionnelles. Je pensais que le commutateur -g s'occuperait de cela, mais cela ne change rien malheureusement.

J'ai très brièvement essayé de voir ce qui se passe lorsque vous supprimez le bundle .app (déplacez-le dans la corbeille, videz la corbeille) et le remplacez par un nouveau bundle .app portant le même nom. Mes observations sont que lorsque vous supprimez l'ancien, l'entrée dans FDA dans les préférences système disparaît, mais lorsque vous remettez le nouveau au même endroit, l'entrée réapparaît, indiquant que le système reconnaît et considérerait le nouveau .app avoir la FDA. Cependant, lorsque j'ai exécuté la nouvelle application par la suite, j'ai récupéré les erreurs d'origine. Une fois que j'ai supprimé l'entrée FDA pour l'application dans les préférences système et ajouté une nouvelle entrée FDA, les erreurs ont de nouveau disparu. Donc, pour l'instant, je suppose que lors du remplacement du bundle .app, je dois également remplacer l'entrée FDA, pour que cela fonctionne. Il se pourrait très bien que si l'on remplace simplement des parties du bundle .app, il continuera à fonctionner. Cela nécessite une enquête plus approfondie de l'AFAICT.

Pour tous ceux qui souhaitent regrouper restic dans un ensemble .app, voici un didacticiel quelque peu générique que j'ai écrit il y a quelques mois sur la façon de le faire pour n'importe quel programme Go, y compris le code si vous voulez juste modifier quelques paramètres et être sur votre manière : https://medium.com/@mattholt/packaging -a-go-application-for-macos-f7084b00f6b5

10.14.3 -- toujours pas de bonnes nouvelles pour l'exécution avec le binaire uniquement.

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

Fonctionne si Terminal.app est ajouté à FDA, mais pas avec seulement ls (ou d'autres binaires).

applescript/automator fonctionne mais affiche une icône dans le dock ; alternativement, en utilisant xcode/swift cli, compilez ceci dans un binaire et ajoutez-le à la FDA (remplacez /full/path/to par vos vrais chemins)

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 pas de chance ici.

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

J'ai récemment commencé à utiliser Restic et j'ai essayé de le faire fonctionner comme une tâche cron appelée à partir de la racine crontab sudo crontab -e afin que je puisse me sentir un peu plus en sécurité en ayant mon script de sauvegarde dans un fichier accessible uniquement avec sudo privilèges . J'obtenais exactement les mêmes erreurs que @ n8henrie mais maintenant j'ai une solution de travail et j'aimerais savoir si cela fonctionne pour les autres ici.

Tout d'abord un petit rappel de ma configuration :

J'ai un script de sauvegarde dans /Users/myuser/bin nommé restic-backup.sh avec des permissions 700 (uniquement root/sudo read/write/execute). J'exécute ce fichier avec mon root crontab sudo crontab -e . J'utilise iTerm comme terminal par défaut. J'ai installé restic et zsh avec Homebrew.

mac OS version 10.14.5

restic-backup.sh :

Mon fichier de script de sauvegarde contient les éléments suivants.

#!/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

Puis dans mon fichier crontab racine : sudo crontab -e j'ai :

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

En accès complet au disque :

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

Comme @n8henrie , je pensais que les programmes accédant réellement aux fichiers comme restic seraient ceux qui auraient besoin de la FDA, mais à la place, il semble que les programmes faisant la demande initiale sudo aient besoin de la FDA : cron dans le cas automatisé et iTerm.app dans le cas manuel.

J'ai découvert quelque chose d'utile : lorsqu'une application est mise sur liste blanche, elle s'applique à tout script ou fichier binaire dans le répertoire de l'application. Ainsi, vous n'avez pas à lancer l'application directement. En fait, l'application elle-même est complètement hors de propos - elle agit simplement comme un conteneur pour la liste blanche. Vous pouvez copier votre script dans une application arbitraire, ajouter cette application à la liste blanche, puis exécuter votre script. La seule mise en garde est que vous devez supprimer et rajouter l'application à la liste blanche chaque fois que vous modifiez votre script ou votre binaire.

@atticusmatticus @russelldavis - Je pense que l'une des récentes mises à jour de MacOS a peut-être encore changé quelque chose - j'avais définitivement essayé ces deux stratégies sans succès. Mais j'avais aussi essayé le ci-dessous, qui avait cessé de fonctionner, mais fonctionne à nouveau (en quelque sorte):

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. Ajoutez le binaire gotest (et rien d'autre) à l'accès complet au disque
3. copier le plist dans ~/Library/LaunchAgents/
4. Chargez le démon launchd : launchctl load -w ~/Library/LaunchAgents/com.me.gotest.plist

Maintenant, curieusement, avec le binaire gotest , mais pas launchd (ou launchctl ) ajouté à FDA, je ne peux toujours pas exécuter directement :

$ 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

Mais il s'exécute sans erreur à partir du démon launchd (toutes les 15 secondes tel que configuré), qui ne s'exécute pas en tant que root ( ~/Library/ not /Library/ , and launchctl load not sudo launchctl load ):

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

Curieusement, je vois toujours, y compris un redémarrage :

||passer en binaire dans la FDA|passer en binaire pas dans la FDA
---|:---:|:---:
passer au binaire sans sudo |err|err
aller en binaire avec sudo |err|err
launchd exécutant go binary|RUNS|err

Pas directement lié au restic, mais au problème de la FDA.
Je pense que j'ai une idée de comment cela fonctionne probablement et j'espère que je n'ai pas été capitaine évident. Je n'ai pas encore trouvé de discussion, d'article ou de documentation utile à ce sujet.

La FDA fonctionne pour les applications qui étaient sur la liste blanche (l'ouverture signifie qu'elles sont lancées par launchd), pour tous les processus enfants de ces applications, même ceux qui ne sont pas sur la liste blanche et pour les binaires sur la liste blanche s'ils sont directement lancés par launchd ( launchd.plist ou launchctl submit ). Cela ne fonctionne pas si le binaire en liste blanche est lancé dans une arborescence de processus avec une application/un binaire parent non en liste blanche.

À partir de là, il semble que c'est launchd qui est responsable de l'arborescence des processus de la liste blanche en fonction de l'application/du binaire ajouté à la liste blanche.

D'après les expériences, il semble que le chemin vers le binaire devrait être exact, donc la liste blanche ne sera pas déclenchée si pour le binaire de la liste blanche, launchctl plist a WorkingDirectory spécifié et le chemin relatif ./some-binary est utilisé, cela ne fonctionnera même pas pour /some/path/./some-binary ou /some/path/../path/some-binary , seulement /some/path/some-binary .
Il n'est pas non plus possible d'utiliser une application sur liste blanche pour shebang même si le script est lancé directement par launchd , donc #!/some/path/some-binary ne fonctionnera pas, seulement /some/path/some-binary /path/to/script .

Oui, je cours à partir de launchd . Quelques lectures intéressantes ici

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/

Je pense que nous avons suffisamment d'informations et de points de données pour fournir au moins quelques lignes directrices (et peut-être un lien vers ce problème) dans les documents, et j'aimerais commencer à travailler dessus si cela vous convient.

Cela devrait-il être un nouveau point sous Exemples , comme la section sur la sauvegarde sans s'exécuter en tant que root sous Linux ?

Je compte noter que :

• Un accès complet au disque est requis pour sauvegarder autant de disque que possible
• Un script launchd exécuté en tant que root peut appeler un binaire qui est sur la liste blanche de la FDA sans avoir besoin d'ajouter launchd à la FDA
• À moins que Terminal.app ne soit répertorié dans FDA, le binaire ne peut pas accéder au disque complet lorsqu'il est appelé depuis Terminal
• Si Terminal.app est répertorié dans FDA, il peut accéder au disque complet lorsqu'il appelle un binaire, que ce binaire soit ou non dans FDA

Est-ce que cela semble refléter la compréhension et l'expérience de chacun ?

Bien que quelque peu alambiqué, j'ai été satisfait de ma configuration fonctionnant sur 2 Macbooks au cours du dernier > 1 an, et j'en inclurais probablement des parties à titre d'exemple. Ma configuration est:

• J'ai un script shell qui exécute une commande restic spécifique à la machine basée sur diverses variables d'environnement (le même script s'exécute également sur 4 ordinateurs Linux, qui appellent directement ce script).
• Sur mes ordinateurs MacOS, je construis un binaire go qui exécute simplement le script shell ci-dessus. J'utilise ici un script shell pour faciliter la configuration / les mises à jour / le contrôle de version, bien que cela puisse également être facilement fait directement dans Go.
• Ce binaire est ajouté à la FDA
• J'exécute un démon launchd à l'échelle du système (qui s'exécute avec les autorisations root) pour lancer ce binaire go selon un calendrier

L'utilisation d'un binaire similaire à https://github.com/restic/restic/issues/2051#issuecomment -442872479 fonctionne pour moi. Je suis allé avec c car je n'ai pas installé go pour le moment. Pour les autres à copier/coller :

1. sauvegarde.c

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

1. compiler : gcc -Wall -o backup backup.c
2. liste blanche le binaire de sauvegarde et utilisez-le comme vous le souhaitez

Curieusement, je vois toujours, y compris un redémarrage :

aller binaire à la FDA aller binaire pas à la FDA
passer au binaire sans sudo err err
passer au binaire avec sudo euh euh
launchd en cours d'exécution go binaire RUNS erreur

Merci!

La solution pour moi était de créer un fichier .plist qui appelle directement restic et de mettre tous les paramètres à l'intérieur ou dans des fichiers séparés, en utilisant les options -p, --exclude-files, --files-from . Et bien sûr, donnez les autorisations binaires restic de la FDA :

<?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>

Comment trouver quelle application doit être ajoutée à la FDA ? En bref, trouvez l'application qui l'exécute.

Vous pouvez laisser le processus en cours d'exécution et parcourir le pid parent du processus jusqu'à ce que le pid ancêtre soit 1, lancé via ps ajx ou ps ao pid,ppid,command avec grep .

Et en bref :

• exécuté via crontab, /usr/sbin/cron , obsolète par launchd.plist
• exécuté via launchd.plist, le binaire dans Program ou ProgramArguments
• exécuter dans Terminal, Terminal.app
• exécuter via ssh, /usr/libexec/sshd-keygen-wrapper ou similaire
• exécuter via une autre application, trouvez-le.

Donc, pour @n8henrie , vous devez trouver le binaire réel.

Une autre façon de résoudre ce problème si vous exécutez des choses via launchd : LaunchControl est désormais livré avec un assistant appelé fdautil que vous pouvez ajouter à la liste blanche, puis exécutez des commandes à l'aide fdautil exec . Il n'autorisera que les commandes que vous avez ajoutées à la liste blanche via LaunchControl ou fdautil set .

Il y a un peu d'informations à ce sujet sur https://www.soma-zone.com/LaunchControl/FAQ.html , et plus de détails dans la fenêtre d'aide de l'application.