Restic: MacOS Mojave: error: Abrir: ... operación no permitida

Sí, aparentemente tienes que hacer el acceso completo al disco: https://www.backblaze.com/blog/mojave-permissions/

¿Está _seguro_ de haber agregado el binario restic correcto? ¿Movió el archivo o cambió alguno de sus atributos (propiedad, etc.) después de agregarlo a Acceso total al disco en Preferencias del sistema?

(Tengo una Mac, pero aún no tengo Mojave, lo siento).

Uso homebrew, así que primero agregué /usr/local/bin/restic a Acceso total al disco, comencé un trabajo, anoté los mismos errores, luego lo eliminé y agregué la ruta al binario real (observando que esto desafortunadamente tendría que ser se rehace cada vez que se actualiza restic): /usr/local/Cellar/restic/0.9.2/bin/restic , lamentablemente veo los mismos errores.

Sin cambios, se agregó binario a Acceso total al disco, se volvió a la terminal y se ejecutó sudo myscript.sh , que funcionó para la mayoría de los archivos pero dio errores de permiso en otros.

Nota al margen, hay otro problema (posiblemente relacionado con Mojave) que estoy tratando de desarrollar, donde mi autenticación de clave pública sftp dejó de funcionar cuando se ejecuta desde launchctl (como root), pero funciona cuando se ejecuta manualmente como root, pero lo haré presentar un nuevo problema si puedo determinar que no es específico de mi configuración.

Interesante. ¿Qué pasa si ejecutas restic directamente? Y/o agregue su script a la FDA. Simplemente disparando en la oscuridad aquí, honestamente. Si tuviera Mojave lo probaría.

Buen pensamiento.

Mi script en sí no es ejecutable (realmente sin una buena razón), como se señaló, lo ejecuto con sudo bash myscript.sh ( /usr/local/bin/bash en realidad); no se puede agregar a FDA porque no es ejecutable.

Intenté agregar /usr/local/bin/bash a la FDA y nada.

EDITAR: aparentemente me equivoco, incluso después chmod +x , mi backup.sh aún no se puede agregar directamente a FDA (mientras que los binarios bash y restic poder). Impar.

EDIT2: solo para ser exhaustivo, agregué los binarios bash y restic a FDA y veo el mismo error.

Probablemente sea un problema mayor que restic: incluso intenté agregar /bin/ls a la lista de la FDA y sigo recibiendo un error.

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

EDITAR: Solución fea: agregue Terminal.app a los permisos de la FDA y los errores de permisos desaparecerán.

Hilo relevante: https://forums.developer.apple.com/thread/107546

Intenté codesign tanto el binario restic como mi script backup.sh y lo agregué a FDA, sin suerte.

(Después de leer algo de ese hilo) Dios mío. Esto es súper molesto. ¡Gracias por investigarlo! Seguiré investigando también una vez que actualice...

Wow, muchas gracias por la información y todo el tiempo que le dedicaste al problema! No tengo una Mac en absoluto, así que me alegro si ambos pudieron resolverlo y podemos documentar este problema para otros usuarios. ¡Gracias de nuevo!

@mholt Si lo desea, puede instalar una prueba de 30 días de VMware Fusion e instalar Mojave en eso (a menos que Apple paralice la capacidad de instalarlo ad-hoc). Esa versión de prueba no contamina y se puede desinstalar si no lo desea más adelante.

Señalé anteriormente que agregar Terminal.app a la lista System Preferences -> Security & Privacy -> Full Disk Access era una solución, ya que cuando ejecuté manualmente mi script ( sudo /usr/local/bin/bash mybackup.sh ) parecía funcionar sin los errores de permisos.

Por alguna razón, cuando revisé mis registros esta mañana de la ejecución restic automática durante la noche (basada en un script launchd en /Library/LaunchDaemons/com.n8henrie.restic.plist que se ejecuta todas las noches con privilegios de root), los errores de permisos aún están ahí.

Y desafortunadamente, ahora no puedo hacer que la solución funcione, incluso con Terminal.app en FDA, sigo recibiendo los errores de permisos cuando ejecuto sudo launchctl start com.n8henrie.restic o sudo /usr/local/bin/bash mybackup.sh .

Entonces, la solución alternativa no parece funcionar, o algo ha cambiado.

EDITAR: Gah, acabo de agregar los 3 a la FDA: Terminal.app , /usr/local/bin/bash y /usr/local/Cellar/restic/0.9.2/bin/restic , y ahora se ejecutó sin errores. 🤷‍♂️

FWIW, aquí está mi salida de registro , que contiene la lista de archivos que obtienen errores. Como puede ver, hay algunas preocupaciones importantes, como mi biblioteca de fotos.

@ n8henrie Desde el hilo de soporte de Mac al que se vinculó anteriormente, parece que la FDA requiere que las aplicaciones aprobadas sean un paquete .app registrado en la carpeta Aplicaciones, lo que podría ser la razón por la cual Terminal.app tiene éxito ... pero debe agregar los 3 a la FDA en su caso? Interesante...

@mholt parece que está pasando algo más. Dejé mi configuración exactamente como estaba ayer (los 3 en FDA, que no produjeron errores de permisos), y mi ejecución nocturna todavía tenía los mismos errores de permisos anteriores.

Esto ha sucedido dos veces ahora, donde después de jugar por un tiempo obtengo ejecuciones sin errores de permisos que luego vuelven a aparecer. ¿Ristic de alguna manera sabe si un archivo ha cambiado o no sin necesidad de abrir el archivo, algún tipo de caché? Me pregunto si me están engañando las ejecuciones que se realizan muy juntas, y no ha habido cambios intermedios en un archivo y, por lo tanto, restic no intenta abrirlo.

De lo contrario, estoy teniendo dificultades para explicar lo que está pasando aquí.

Buena pregunta. Sé que restic usa un caché, pero no he investigado cuán agresivamente se adhiere a él en el caso de errores de permisos, etc.

Discusión relevante en SO: https://apple.stackexchange.com/q/338213/27415

Buena pregunta. Sé que restic usa un caché, pero no he investigado cuán agresivamente se adhiere a él en el caso de errores de permisos, etc.

Para nada. El caché solo contiene archivos del repositorio, no se incluye información sobre el sistema de archivos (que no está en el repositorio).

De acuerdo, sí, no creo que esto sea un error en restic. Este es definitivamente un problema de macOS Mojave que, en este punto, estoy bastante seguro de que restic no puede hacer nada para solucionarlo.

Genial, gracias por los comentarios, estoy cerrando este tema por ahora. Por favor agregue más comentarios si descubre cosas. ¡Gracias!

Estoy un poco sorprendido de ver que el problema ya está cerrado; esto parece una
incompatibilidad importante con una plataforma importante y cerrarla en este punto
puede ponerlo "fuera de la vista, fuera de la mente".

Entiendo que esto no es principalmente un problema de restic, pero parece que
hay algunos pasos razonables que se pueden tomar para los usuarios de MacOS. Como es,
la capacidad de un usuario para realizar una copia de seguridad de gran parte de sus datos personales más importantes
los datos (por ejemplo, fotos) están comprometidos de forma predeterminada en la versión actual de
Mac OS. ¡Eso me parece un gran problema, para cualquier software de respaldo!

Algunas sugerencias / posibilidades (en las que me complace ayudar a trabajar):

• Posibilidades de solucionar el problema
  
  
  
  • ¿Es posible proporcionar una aplicación contenedora de MacOS adecuada que
    
    se puede agregar a la lista de la FDA, que contiene el binario restic
  
  
  • Si puede descubrir cómo hacer lo anterior, en lugar de proporcionar el
    
    aplicación, ¿podríamos incluir instrucciones sobre cómo los usuarios pueden lograrlo?
    
    ellos mismos con algún tipo de Makefile o XCode?
  
  
• Soluciones alternativas
  
  
  
  • Proporcione información en los documentos sobre los binarios más seguros/mínimos
    
    que deben agregarse a la FDA
  
  
  • Proporcione enlaces a información sobre (y riesgos de) deshabilitar SIP
  
  
• Advertencias
  
  
  
  • Incluya información en los documentos en algún lugar que los usuarios de Mojave no tendrán
    
    sus datos completamente respaldados por defecto
  
  

En general, la situación no parece muy diferente a la copia de seguridad completa sin root
en Linux, deshabilitar SIP por completo es algo así como ejecutar como
raíz, y determinando y recomendando un compromiso razonablemente seguro con
FDA es algo así como usar setcap .

Desafortunadamente, mi Macbook está en la tienda esta semana, así que no podré
trabajar en cualquiera de estos de inmediato, pero me interesaría escuchar opiniones
de otros; tal vez estoy muy equivocado, o posiblemente ignoro los detalles de
el flujo de trabajo del equipo restic para la gestión de problemas.

Algunas actualizaciones más ahora que recuperé mi máquina:

No puedo replicar mis éxitos anteriores al obtener una copia de seguridad completa del sistema desde mi script de inicio.

Intenté agregar todo lo siguiente a la lista de la FDA (al mismo tiempo) y aún obtengo los errores:

• descanso
• intento
• lanzarctl
• lanzado
• Terminal.app

Solo para experimentar, los binarios simples parecen funcionar bien cuando se agregan a la lista de la FDA y no parecen tener nada que ver con el diseño conjunto. Compare los binarios ls proporcionados por MacOS y por 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

Antes y agregando a la lista de la 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

Además, funcionan bien cuando se colocan en un script bash siempre que ls esté en FDA (no es necesario agregar bash por separado), lo que me hace pensar que solo debería agregar restic .

Además, a modo de comparación, ejecute los siguientes errores de script de Go si no está en FDA, pero funciona bien por sí solo y cuando se llama desde launchd siempre que el binario esté en FDA (no es necesario agregar launchd / launchctl / cualquier otra cosa).

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

Producción:

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

A continuación, experimentaré un poco con Restic para ver si puedo averiguar por qué está recibiendo errores de permiso incluso cuando se agrega a FDA (aunque parece que otros binarios funcionan una vez que se agregan).

Bien, gracias por los comentarios. Reabriré este problema, tal vez podamos averiguar qué está pasando y luego agregar algo de documentación al manual.

~Sigo recibiendo errores de Open en un repositorio nuevo, con restic agregados a la lista de la FDA.~

Ver editar a continuación.

$ 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

EDITAR: ignore este comentario: todavía estoy plagado de errores intermitentes que confunden cualquier progreso, tal vez en asociación con la actualización a MacOS 10.14.1 ayer. Hoy, el mismo código Go de ayer que funcionó consistentemente con FDA y falló sin él (lo activé y desactivé varias veces para estar seguro) ya no funciona ni siquiera con FDA . Lo mismo con ls .

Funciona si se agrega Terminal.app a FDA (como única entrada), lo que no era necesario ayer.

🤷‍♂️

Informaré si puedo encontrar algo sobre esto en los foros de Apple.

EDIT2: Wife's Macbook todavía está en 10.14, y /bin/ls ~/Library/Mail no funciona con /bin/ls agregado a FDA, por lo que parece que puede no ser algo nuevo en 10.14.1. 😕

Todavía estoy trabajando en esto.

Sigue siendo bastante doloroso, pero finalmente tengo una solución que creo que funcionará para mis propósitos.

He detallado el proceso aquí , pero la conclusión es:

Puede usar Script Editor.app para convertir un AppleScript en un paquete de aplicaciones. Ese AppleScript puede ejecutar su secuencia de comandos de respaldo restic (en mi caso /path/to/restic-backup.sh , donde restic-backup.sh es una secuencia de comandos bash que ejecuta restic con mi configuración deseada), y puede agregar el paquete de aplicaciones resultante a FDA en para obtener acceso a los archivos protegidos.

Sin embargo, esto dificulta la automatización de la ejecución de copias de seguridad a nivel del sistema. El comando incorporado open funciona, pero ejecuta la aplicación bajo su usuario; por lo tanto, mientras se realiza una copia de seguridad de los archivos protegidos por la FDA anteriores, obtendrá errores de permisos en cualquier archivo que solo sea legible por root (por ejemplo, root -propiedad de 0600 cosas).

Mi solución en este punto es hacer que AppleScript llame al script de respaldo con sudo y le otorgue a mi usuario privilegios para ejecutar ese script con privilegios de root sin contraseña ( sudo visudo , NOPASSWD: , etc).

No es bonito, pero parece estar funcionando.

Me gustaría dejar esto abierto para sugerencias de usuarios de MacOS con más experiencia. Si no surge nada más satisfactorio, podría agregar esta información a los documentos (aunque, sinceramente, esta solución no parece muy satisfactoria).

Increíble, esto parece funcionar y es mucho más limpio y 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)
    }
}

El binario resultante puede ser chown root y chmod 0700 , luego se agrega a Full Disk Access y parece funcionar. Luego se puede agregar a una lista /Library/LaunchDaemons para que se ejecute automáticamente.

Las primeras 2 ejecuciones están funcionando hasta ahora, espero que esto no termine como varios inicios en falso anteriores.

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

Mi ejecución automática de anoche funcionó. Estoy implementando esta estrategia en el Macbook Air de mi esposa hoy, si parece que también funciona allí, lo consideraré una solución razonable y trabajaré en un pequeño PR para https://github.com/restic/restic. net (si eso parece razonable).

Hola @n8henrie , vine aquí después de encontrar este problema exacto y luego encontré la publicación de tu blog. Gracias por hacer toda esta investigación.

La solución anterior (llamar al script de shell desde el binario Go simple) no funciona para mí. ¿Estás seguro de que está accediendo con éxito a todos tus archivos?

Observé en particular que stdout/stderr se descarta en /dev/null. Tampoco puede leer la entrada estándar si, por ejemplo, restic quiere solicitar una contraseña. (También es gracioso, ¿por qué tu bash es /usr/local/bin/bash y no /bin/bash ? Solo por curiosidad).

De todos modos, hice los siguientes cambios para ver el resultado del error:

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

Antes de ver la publicación de su blog, mi primer instinto fue agregar el binario restic en sí mismo a la FDA, y eso no funcionó para mí en 10.14.1 (18B75). No estoy seguro de por qué la inserción de otro programa (el envoltorio Go llamando a un script de shell, en última instancia, llamando a restic) cambiaría algo.

¿Esto sigue funcionando para ti?

@ n8henrie gracias por mantenernos informados! También puede escribir una publicación de blog sobre esto en el blog restic si está dispuesto a hacerlo (además de una pequeña sección en el manual más o menos)... :)

@fd0 ¡Me sentiría honrado!

@armhold sí, parece estar funcionando a las mil maravillas, mira a continuación. En el MBA de mi esposa, creo que necesité reiniciar antes de que comenzara a funcionar (aunque no en el mío). IIRC para ella, creé el binario, luego reinicié, luego agregué a FDA, y funcionó.

Antes de la corrección:

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

Después de la corrección:

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

La misma solución también funciona en el Macbook Air de mi esposa, ambos verificados en el control remoto con restic find '/Users/*/Library/Mail' --snapshot latest --host=$(hostname) (donde ~/Library/Mail es uno de los directorios generalmente protegidos, como se puede ver en el registro de errores anterior) .

Observé en particular que stdout/stderr se descarta en /dev/null. Tampoco puede leer la entrada estándar si, por ejemplo, restic quiere solicitar una contraseña.

Esto dependerá completamente de su guión. Como puede ver en mi publicación original, dado que mi configuración está completamente automatizada, está configurada para leer la contraseña de un archivo (propiedad de la raíz 0600), pero también podría leer desde un envvar o cualquiera de los métodos habituales. Tienes razón, no creo que esto funcione para cosas interactivas. También registra todo en un archivo: &>> /path/to/file.log .

(También es divertido, ¿por qué bash es /usr/local/bin/bash y no /bin/bash? Solo por curiosidad).

Uso Homebrew para obtener una versión más reciente 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.

Esto me brinda funciones más modernas, como el operador &>file.log (que ahorra algunas pulsaciones de teclas en comparación con 2>&1 >file.log .

Antes de ver la publicación de su blog, mi primer instinto fue agregar el binario restic en sí mismo a la FDA, y eso no funcionó para mí en 10.14.1 (18B75). No estoy seguro de por qué la inserción de otro programa (el envoltorio Go llamando a un script de shell, en última instancia, llamando a restic) cambiaría algo.

Tampoco estoy completamente seguro de esto. Para mi caso de uso, tengo muchas otras configuraciones que hago en mi script bash (comando sftp algo complicado donde el destino, las rutas de respaldo y varias opciones se basan en el nombre de host), por lo que llamar al binario restic en sí no fue una opción. Puedo experimentar un poco con eso.

Vale, gracias por la explicación. Acabo de intentar reconstruir, reiniciar + agregar FDA, y sigo recibiendo operation not permitted . También intenté mover tanto el contenedor binario como el script de shell a /Aplicaciones, y no hubo suerte. Seguiré cavando.

Eh. Definitivamente no necesita estar en /Aplicaciones para mí.

¿Estás en 10.14 o 10.14.1? Estoy en este último.

Y puede intentar usar el comando tccutil al que me referí para borrar todas las entradas de antemano.

Estoy en 10.14.1 (18B75). También probé el comando tccutil, sin suerte. Entiendo por qué Apple está haciendo esto, pero es realmente frustrante no tener un camino claro sobre qué hacer aquí.

Eh. Esto es raro.

Curiosamente, lo intenté y no puedo hacer que el binario restic funcione directamente.

No está claro por qué esto no funciona, pero mi solución es (para mí).

Parece otro error intermitente. Creo que deberíamos esperar
documentación formal / redacción hasta que podamos obtener la de otra persona
ordenador trabajando con el mismo sistema. Estoy 2 por 2, pero no veo por qué
esto no funciona para @armhold.

@armhold , ¿puede publicar una copia del script bash exacto y el código Go que está
usando y cómo lo estás ejecutando? Voy a ver si puedo reproducir en mi extremo.

Curiosamente, lo intenté y no puedo hacer que el binario restic funcione directamente.

Sí, eso es lo que no entiendo. No veo por qué el envoltorio Go tendría éxito donde el binario restic fallaría. Algo parece estar mal.

¿Puede publicar una copia del script bash exacto y el código Go que está usando y cómo lo está ejecutando?

Claro, aquí está: https://github.com/armhold/restic-fda.

• tanto el script de shell como el envoltorio go están instalados en mi directorio ~/bin .
• agregó ~/bin/restic-fda a FDA a través de Preferencias del sistema
• Estoy ejecutando restic-fda desde una cuenta de usuario que no es raíz de forma interactiva en la línea de comando en la Terminal. Recibo errores como: error: Open: open /Users/armhold/Library/Application Support/AddressBook: operation not permitted .
• ejecutar como root (a través de Sudo) falla de manera similar

No he intentado ejecutarlo a través de launchctl.

Little Snitch, un cortafuegos, hace algo similar: para las conexiones salientes, preguntaría si permitir que "Terminal a través de restic" haga la conexión (en lugar de solo restic); es decir, Terminal.app es el principal para otorgar permiso.

Lo que hice al final fue agrupar mi script de shell como una aplicación usando Platypus y otorgar FDA a esa aplicación generada. Luego inicie copias de seguridad a través de Finder. Funciona hasta ahora.

launchctl será el siguiente paso.

FYI, esto todavía funciona para mí (incluso después de MacOS más reciente
actualizar). ¿Alguna noticia de @armhold?

Todavía no funciona para mí. Me rendí y acabo de dar Terminal FDA.

Desafortunadamente, estoy perplejo de nuevo.

Estoy en 10.14.2. Mi script de copia de seguridad restic sigue funcionando, no hay errores de permisos en sus registros. Sin embargo, ahora no puedo hacer funcionar el script de @armhold o incluso mis scripts de prueba anteriores (que no hacen nada más que abrir el directorio protegido ~/Library/Mail ).

🤷‍♂️

¿Ha intentado ejecutar su contenedor (de trabajo) en un repositorio nuevo? Lo que quiero decir es, ¿está seguro de que no está saltando archivos que son antiguos y, por lo tanto, ya están presentes en el repositorio? Sin embargo, me imagino que todavía obtendría un error al intentar descender a las carpetas protegidas, ya que restic camina por el árbol.

@mholt ¿Cuál es el estado de esto y la reliquia? ¿Ha solucionado esto de alguna manera y, de ser así, puede compartir con nosotros qué pasos ha tomado para hacerlo?

Después de actualizar un par de clientes, también veo este comportamiento, muy molesto y difícil de manejar sin envolver cosas y perder el tiempo.

@rawtaz

¿Cuál es el estado de esto y la reliquia? ¿Ha solucionado el problema de alguna manera y, de ser así, puede compartir con nosotros qué pasos ha tomado para hacerlo?

Solo me actualicé a Mojave la semana pasada. Pero instalé Relica y pude reproducir el error de "operación no permitida" al intentar hacer una copia de seguridad de ~/Library/Mail.

Luego agregué Relica.app a la pantalla FDA y volví a ejecutar la copia de seguridad de Relica.

Se realizó una copia de seguridad sin errores esta vez (mientras que la primera instantánea realizada por Relica+restic no mostró la carpeta de correo en absoluto debido al error de permiso):

Así que me temo que no tengo ninguna respuesta para contribuir a este hilo. :-/ No estoy seguro de si _seguirá_ funcionando pero, por supuesto, espero que sí.

Yo también decidí envolver mi secuencia de comandos de respaldo restic en un paquete .app para poder darle la FDA. Apesta tener que hacer esto, pero parece ser la única forma práctica de avanzar.

Al principio intenté dar solo el FDA binario restic, pero eso no funcionó.
También intenté dar mi script de respaldo (un script Bash que llama a restic) FDA, pero tampoco funcionó.
No probé el envoltorio de @armhold .

Usé Platypus como se sugirió anteriormente, y funciona muy bien. Produce un paquete .app que luego puedo darle a FDA en la configuración del sistema de macOS, y esto resuelve el problema.

El único inconveniente que he notado durante el uso es que cuando se inicia .app (para mí, se inicia con crontab usando open -ga ~/Applications/Backup.app , la ventana actual pierde el foco. Esto puede ser una molestia grave para mis usuarios, pero es lo que es. Al menos tenemos copias de seguridad que funcionan de nuevo. Pensé que el interruptor -g se encargaría de eso, pero desafortunadamente no cambia nada.

Traté brevemente de ver qué sucede cuando elimina el paquete .app (moverlo a la Papelera, vaciar la papelera) y reemplazarlo con un nuevo paquete .app con el mismo nombre. Mis observaciones son que cuando eliminas el anterior, la entrada en FDA en las preferencias del sistema desaparece, pero cuando vuelves a colocar el nuevo en el mismo lugar, la entrada aparece nuevamente, lo que indica que el sistema reconoce y consideraría el nuevo .app tener FDA. Sin embargo, cuando ejecuté la nueva aplicación después de eso, recuperé los errores originales. Una vez que eliminé la entrada de la FDA para la aplicación en las preferencias del sistema y agregué una nueva entrada de la FDA, los errores desaparecieron nuevamente. Entonces, por ahora, supongo que al reemplazar el paquete .app, también necesito reemplazar la entrada FDA para que funcione. Es muy posible que si uno simplemente reemplaza partes del paquete .app, seguirá funcionando. Esto necesita más investigación AFAICT.

Para cualquiera que quiera agrupar restic en un paquete .app, aquí hay un tutorial un tanto genérico que escribí hace unos meses sobre cómo hacerlo para cualquier programa Go, incluido el código si solo desea cambiar algunas configuraciones y estar en su vía: https://medium.com/@mattholt/packaging-a-go-application-for-macos-f7084b00f6b5

10.14.3: todavía no hay buenas noticias para ejecutar solo con binario.

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

Funciona si se agrega Terminal.app a FDA, pero no solo con ls (u otros binarios).

applescript/automator funciona pero muestra un icono en el muelle; alternativamente, usando xcode/swift cli, compile esto en un binario y agréguelo a la FDA (reemplace /full/path/to con sus rutas reales)

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 no hubo suerte aquí.

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

Recientemente comencé a usar Restic y he estado tratando de hacer que funcione como un trabajo cron llamado desde el crontab raíz sudo crontab -e para poder sentirme un poco más seguro al tener mi secuencia de comandos de respaldo en un archivo al que solo se puede acceder con privilegios sudo. . Obtuve exactamente los mismos errores que @ n8henrie, pero ahora tengo una solución que funciona y me gustaría saber si esto funciona para otros aquí.

Primero un poco de historia de mi configuración:

Tengo un script de respaldo en /Users/myuser/bin llamado restic-backup.sh con permisos 700 (solo root/sudo leer/escribir/ejecutar). Ejecuto este archivo con mi root crontab sudo crontab -e . Uso iTerm como mi terminal predeterminado. He instalado restic y zsh con Homebrew.

macOS versión 10.14.5

restic-backup.sh:

Mi archivo de script de respaldo tiene lo siguiente.

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

Luego, en mi archivo raíz crontab: sudo crontab -e tengo:

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

En acceso total al disco:

cron ==> /usr/sbin/cron
iTerm.aplicación ==> /Applications/iTerm.app

Al igual que @n8henrie , pensé que los programas que realmente acceden a los archivos como restic serían los que requieren la FDA, pero en cambio, parece que los programas que realizan la solicitud inicial sudo necesitan la FDA: cron en el caso automatizado y iTerm.app en el caso manual.

Descubrí algo útil: cuando una aplicación está en la lista blanca, se aplica a cualquier secuencia de comandos o binario dentro del directorio de la aplicación. Por lo tanto, no tiene que iniciar la aplicación directamente. De hecho, la aplicación en sí es completamente irrelevante: simplemente actúa como un contenedor para la lista blanca. Puede copiar su secuencia de comandos en una aplicación arbitraria, incluir esa aplicación en la lista blanca y luego ejecutar su secuencia de comandos. La única advertencia es que debe eliminar y volver a agregar la aplicación a la lista blanca cada vez que cambie su secuencia de comandos o binario dentro de ella.

@atticusmatticus @russelldavis : creo que una de las actualizaciones recientes de MacOS puede haber cambiado algo nuevamente: definitivamente probé ambas estrategias sin suerte. Pero también probé lo siguiente, que había dejado de funcionar, pero ahora está funcionando nuevamente (más o menos):

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. Agregue el binario gotest (y nada más) a Acceso total al disco
3. copie la lista a ~/Library/LaunchAgents/
4. Cargue el demonio launchd: launchctl load -w ~/Library/LaunchAgents/com.me.gotest.plist

Ahora, curiosamente, con el binario gotest , pero no launchd (o launchctl ) agregado a FDA, todavía no puedo ejecutar directamente:

$ 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

Pero se ejecuta sin errores desde el daemon launchd (cada 15 segundos según lo configurado), que no se ejecuta como raíz ( ~/Library/ no /Library/ , y launchctl load no sudo launchctl load ):

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

Curiosamente, sigo viendo, incluido un reinicio:

||ir a binario en FDA|ir a binario no en FDA
---|:---:|:---:
ir binario sin sudo |err|err
ir binario con sudo |err|err
launchd ejecutando go binary|RUNS|err

No está directamente relacionado con el restic, sino con el problema de la FDA.
Creo que tengo una idea de cómo probablemente funciona y espero no haber sido el capitán obvio. Todavía no pude encontrar una discusión, artículo o documentación útil sobre.

FDA funciona para las aplicaciones que se incluyeron en la lista blanca (la apertura significa que se iniciaron mediante el lanzamiento), para cualquier proceso secundario de esas aplicaciones, incluso las que no están en la lista blanca, y para los archivos binarios incluidos en la lista blanca si se inician directamente con launchd ( launchd.plist o launchctl submit ). No funciona si el binario incluido en la lista blanca se inicia en un árbol de procesos con una aplicación principal/binario no incluida en la lista blanca.

A partir de esto, parece que launchd es responsable del árbol de procesos de la lista blanca según la aplicación/binario que se haya incluido en la lista blanca.

A partir de los experimentos, parece que la ruta al binario debe ser exacta, por lo que la lista blanca no se activará si para el binario en lista blanca launchctl plist tiene WorkingDirectory especificado y se usa la ruta relativa ./some-binary , ni siquiera funcionará. por /some/path/./some-binary o /some/path/../path/some-binary , solo /some/path/some-binary .
Tampoco es posible usar la aplicación incluida en la lista blanca para shebang, incluso si se inicia el script directamente con launchd , por lo que #!/some/path/some-binary no funcionará, solo /some/path/some-binary /path/to/script .

Sí, corro desde launchd . Algunas lecturas interesantes aquí

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

https://eclecticlight.co/2018/09/06/trabajando-con-mojaves-privacy-protection/

Creo que tenemos suficiente información y puntos de datos para proporcionar al menos algunas pautas (y tal vez un enlace a este problema) en los documentos, y me gustaría comenzar a trabajar en ello si está bien.

¿Debería ser este un punto nuevo en los Ejemplos , como la sección sobre cómo realizar copias de seguridad sin ejecutar como root en Linux ?

Planeo señalar que:

• Se requiere acceso completo al disco para hacer una copia de seguridad de la mayor cantidad posible del disco
• Una secuencia de comandos launchd que se ejecuta como root puede llamar a un binario que está en la lista blanca de FDA sin necesidad de agregar launchd a FDA
• A menos que Terminal.app figure en la FDA, el binario no puede acceder al disco completo cuando se llama desde Terminal
• Si Terminal.app aparece en FDA, puede acceder al disco completo cuando llama a un binario, ya sea que ese binario esté o no en FDA.

¿Parece que esto refleja la comprensión y la experiencia de todos?

Si bien es un poco intrincado, estoy satisfecho con mi configuración que se ejecuta en 2 Macbooks durante el último> 1 año, y probablemente incluiría partes de ella como ejemplo. Mi configuración es:

• Tengo un script de shell que ejecuta un comando restic específico de la máquina basado en varias variables de entorno (el mismo script también se ejecuta en 4 computadoras Linux, que llaman a este script directamente).
• En mis computadoras MacOS, construyo un binario go que básicamente solo ejecuta el script de shell anterior. Utilizo un script de shell aquí para facilitar la configuración, las actualizaciones y el control de versiones, aunque esto también se puede hacer fácilmente en Go directamente.
• Este binario se agrega a FDA
• Ejecuto un daemon de lanzamiento en todo el sistema (que se ejecuta con permisos de root) para lanzar este binario en un horario

Usar un binario similar a https://github.com/restic/restic/issues/2051#issuecomment -442872479 me funciona. Fui con c porque no tengo go instalado en este momento. Para que otros copien/peguen:

1. copia de seguridad.c

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

1. compilar: gcc -Wall -o backup backup.c
2. incluya en la lista blanca el binario de respaldo y utilícelo como desee

Curiosamente, sigo viendo, incluido un reinicio:

vaya a binario en FDA vaya a binario no en FDA
ir binario sin sudo err err
ir binario con sudo err err
launchd corriendo ir binario EJECUTAR err

¡Gracias!

La solución para mí fue crear un archivo .plist que llame a restic directamente y poner todos los parámetros dentro o en archivos separados, usando las opciones -p, --exclude-files, --files-from. Y, por supuesto, otorga permisos binarios 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>

¿Cómo encontrar qué aplicación se debe agregar a la FDA? En resumen, encuentre la aplicación que lo ejecuta.

Puede mantener el proceso en ejecución y recorrer el pid principal del proceso hasta que el pid principal sea 1, iniciado a través ps ajx o ps ao pid,ppid,command con grep .

Y en resumen:

• ejecutar a través de crontab, /usr/sbin/cron , obsoleto por launchd.plist
• ejecutar a través de launchd.plist, el binario en Program o ProgramArguments
• ejecutar en Terminal, Terminal.app
• ejecutar a través de ssh, /usr/libexec/sshd-keygen-wrapper o similar
• ejecute a través de otra aplicación, encuéntrela.

Entonces, para @n8henrie , necesita encontrar el binario real.

Otra forma de abordar esto si está ejecutando cosas a través de launchd: LaunchControl ahora se envía con un asistente llamado fdautil que puede incluir en la lista blanca y luego ejecutar comandos usando fdautil exec . Solo permitirá los comandos que haya incluido en la lista blanca a través de LaunchControl o fdautil set .

Hay un poco de información al respecto en https://www.soma-zone.com/LaunchControl/FAQ.html y más detalles en la ventana de ayuda de la aplicación.