Restic: MacOS Mojave: erro: Open: ... operação não permitida

Sim, aparentemente você tem que fazer o acesso ao disco completo: https://www.backblaze.com/blog/mojave-permissions/

Você tem certeza de que adicionou o binário restic correto? Você moveu o arquivo ou alterou algum de seus atributos (propriedade, etc.) depois de adicioná-lo ao Full Disk Access nas Preferências do Sistema?

(Eu tenho um Mac, mas ainda não tenho o Mojave, desculpe.)

Eu uso o homebrew, então primeiro adicionei /usr/local/bin/restic ao Full Disk Access, iniciei um trabalho, observei os mesmos erros, então removi isso e adicionei o caminho ao binário real (observando que isso infelizmente teria que ser refeito toda vez que restic atualiza): /usr/local/Cellar/restic/0.9.2/bin/restic , infelizmente vejo os mesmos erros.

Nenhuma alteração, adicionado binário ao Full Disk Access, voltou para o terminal e executou sudo myscript.sh , que funcionou para a maioria dos arquivos, mas deu erros de permissão em outros.

Nota lateral, há outro problema (possivelmente relacionado ao Mojave) que estou tentando detalhar, onde minha autenticação sftp pubkey parou de funcionar quando executada a partir de launchctl (como root), mas funciona quando executada manualmente como root, mas vou arquivar um novo problema se eu conseguir determinar que ele não é específico para minha configuração.

Interessante. O que acontece se você executar restic diretamente? E/ou adicione seu script ao FDA. Apenas atirando no escuro aqui, honestamente. Se eu tivesse Mojave, eu experimentaria.

Bom pensamento.

Meu script em si não é executável (sem uma boa razão realmente), como observado, eu o executo com sudo bash myscript.sh ( /usr/local/bin/bash na verdade); ele não pode ser adicionado ao FDA porque não é executável.

Eu tentei adicionar /usr/local/bin/bash ao FDA e sem dados.

EDIT: aparentemente estou errado, mesmo depois chmod +x , meu backup.sh ainda não pode ser adicionado diretamente ao FDA (enquanto os binários bash e restic posso). Ímpar.

EDIT2: Apenas para ser completo, adicionei os binários bash e restic ao FDA e vejo o mesmo erro.

Provavelmente um problema maior do que restic - eu até tentei adicionar /bin/ls à lista do FDA e ainda recebo um erro.

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

EDIT: Solução feia: adicione Terminal.app às permissões do FDA e os erros de permissão desaparecem.

Tópico relevante: https://forums.developer.apple.com/thread/107546

Tentei codesign ing tanto o binário restic quanto meu script backup.sh e adicionei ao FDA, sem sorte.

(Depois de ler um pouco desse tópico) Meu Deus. Isso é super irritante. Obrigado por olhar para ele! Vou continuar investigando assim que atualizar...

Uau, muito obrigado pelas informações e todo o tempo que você gastou no problema! Eu não tenho um mac, então fico feliz se vocês dois conseguiram descobrir e podemos documentar esse problema para outros usuários! Obrigado novamente!

@mholt Se desejar, você pode instalar uma avaliação de 30 dias do VMware Fusion e instalar o Mojave nele (a menos que a Apple tenha prejudicado a capacidade de instalá-lo ad-hoc). Esse teste não causa poluição e pode ser desinstalado se você não quiser mais tarde.

Observei acima que adicionar Terminal.app à lista System Preferences -> Security & Privacy -> Full Disk Access era uma solução alternativa, pois quando eu executei manualmente meu script ( sudo /usr/local/bin/bash mybackup.sh ) parecia funcionar sem os erros de permissão.

Por alguma razão, quando verifiquei meus logs esta manhã da execução automática durante a noite (com base em um script launchd em /Library/LaunchDaemons/com.n8henrie.restic.plist que é executado todas as noites com privilégios de root), os erros de permissão ainda estão lá.

E, infelizmente, agora não consigo fazer a solução alternativa funcionar - mesmo com Terminal.app no FDA, ainda recebo os erros de permissão quando executo sudo launchctl start com.n8henrie.restic ou sudo /usr/local/bin/bash mybackup.sh .

Portanto, a solução alternativa não parece funcionar ou algo mudou.

EDIT: Gah, acabei de adicionar todos os 3 ao FDA - Terminal.app , /usr/local/bin/bash e /usr/local/Cellar/restic/0.9.2/bin/restic - e agora funcionou sem erros. 🤷‍♂️

FWIW, aqui está minha saída de log , que contém a lista de arquivos recebendo erros. Como você pode ver, existem algumas grandes preocupações, como minha biblioteca de fotos.

@ n8henrie No tópico de suporte do Mac ao qual você vinculou anteriormente, parece que a FDA exige que os aplicativos aprovados sejam um pacote .app registrado na pasta Aplicativos, o que pode ser o motivo pelo qual o Terminal.app é bem-sucedido ... mas você precisa adicionar todos os 3 para a FDA no seu caso? Interessante...

@mholt parece que outra coisa está acontecendo. Deixei minhas configurações exatamente como estavam ontem (todas as 3 no FDA, que não produziram erros de permissão), e minha execução noturna ainda recebeu os mesmos erros de permissão antigos.

Isso já aconteceu duas vezes agora, onde, depois de mexer por um tempo, recebo execuções sem erros de permissão que reaparecem. O restic de alguma forma sabe se um arquivo foi alterado ou não sem precisar abrir o arquivo - algum tipo de cache? Gostaria de saber se estou sendo enganado por execuções que são feitas em conjunto, e não houve alterações temporárias em um arquivo e, portanto, o restic não tenta abri-lo?

Caso contrário, estou tendo dificuldade em explicar o que está acontecendo aqui.

Boa pergunta. Eu sei que o restic usa um cache, mas não analisei o quão agressivamente ele adere a ele no caso de erros de permissão, etc.

Discussão relevante em SO: https://apple.stackexchange.com/q/338213/27415

Boa pergunta. Eu sei que o restic usa um cache, mas não analisei o quão agressivamente ele adere a ele no caso de erros de permissão, etc.

De jeito nenhum. O cache contém apenas arquivos do repositório, nenhuma informação sobre o sistema de arquivos (que não está no repositório) é incluída.

Ok - sim, eu não acho que isso seja um bug no restic. Este é definitivamente um problema do macOS Mojave que, neste momento, tenho certeza que o próprio restic não pode fazer nada para corrigir.

Legal, obrigado pelo feedback, estou encerrando esta questão por enquanto. Por favor, adicione mais comentários se você descobrir coisas. Obrigado!

Estou um pouco surpreso ao ver o problema já encerrado - isso parece um
grande incompatibilidade com uma plataforma principal e fechá-la neste momento
pode colocá-lo "fora de vista, fora da mente".

Eu entendo que isso não é principalmente uma questão de descanso, mas parece que
existem algumas medidas razoáveis ​​que podem ser tomadas para usuários do MacOS. Como é,
a capacidade de um usuário fazer backup de muitos de seus dados pessoais mais importantes
dados (por exemplo, fotos) são comprometidos por padrão na versão atual do
Mac OS. Isso parece um grande negócio para mim, para qualquer software de backup!

Algumas sugestões/possibilidades (que fico feliz em ajudar a trabalhar):

• Possibilidades de correção do problema
  
  
  
  • É possível fornecer um aplicativo de wrapper MacOS adequado que
    
    pode ser adicionado à lista do FDA, que contém o binário restic
  
  
  • Se conseguir descobrir como fazer o acima, em vez de fornecer o
    
    aplicativo, poderíamos incluir instruções sobre como os usuários podem realizá-lo
    
    se com algum tipo de Makefile ou XCode?
  
  
• Soluções alternativas
  
  
  
  • Forneça informações nos documentos sobre os binários mais seguros / mínimos
    
    que precisam ser adicionados ao FDA
  
  
  • Fornecer links para informações sobre (e riscos de) desabilitar o SIP
  
  
• Avisos
  
  
  
  • Inclua informações nos documentos em algum lugar que os usuários do Mojave não terão
    
    seus dados com backup completo por padrão
  
  

No geral, a situação não parece muito diferente do backup completo sem root
no Linux, com desabilitar o SIP completamente sendo algo como executar como
root, e determinar e recomendar um compromisso razoavelmente seguro com
FDA sendo algo como usar setcap .

Infelizmente meu Macbook está na loja esta semana, então não poderei
trabalhar em qualquer um deles imediatamente, mas estou interessado em ouvir pensamentos
de outros; talvez eu esteja fora da base, ou possivelmente ignorante das especificidades de
o fluxo de trabalho da equipe restic para gerenciar problemas.

Mais algumas atualizações agora que tenho minha máquina de volta:

Não consigo replicar meus sucessos acima ao obter um backup completo do sistema do meu script iniciado.

Eu tentei adicionar todos os itens abaixo à lista do FDA (ao mesmo tempo) e ainda recebo os erros:

• descanso
• festança
• launchctl
• lançado
• Terminal.app

Apenas para experimentação, binários simples parecem funcionar bem quando adicionados à lista da FDA e parecem não ter nada a ver com codesign. Compare os binários ls fornecidos pelo MacOS e pelo 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 e adicionando à lista da 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

Além disso, eles funcionam bem quando colocados em um script bash, desde que ls esteja no FDA (sem necessidade de adicionar bash separadamente), o que me faz pensar que eu deveria apenas adicionar restic .

Além disso, para comparação, executando os seguintes erros de script Go, se não estiver no FDA, mas funciona bem por si só, bem como quando chamado de launchd, desde que o binário esteja no FDA (não é necessário adicionar launchd / launchctl / qualquer outra coisa).

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

Saída:

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

Em seguida, farei algumas experiências com o Restic para ver se consigo descobrir por que ele está recebendo erros de permissão mesmo quando adicionado ao FDA (embora outros binários pareçam estar funcionando uma vez adicionados).

Ok, obrigado pelo feedback! Vou reabrir este problema, talvez possamos descobrir o que está acontecendo e então adicionar alguma documentação ao manual.

~Ainda recebendo erros de Open em um novo repositório, com restic adicionado à lista da FDA.~

Veja editar abaixo.

$ 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: Desconsidere este comentário - ainda estou atormentado por erros intermitentes que estão confundindo qualquer progresso, talvez em associação com a atualização para o MacOS 10.14.1 ontem. Hoje, o mesmo código Go de ontem que funcionou consistentemente com o FDA e falhou sem ele (ativei e desativei várias vezes para ter certeza) não está mais funcionando mesmo com o FDA . O mesmo com ls .

Funciona se Terminal.app for adicionado ao FDA (como a única entrada), o que não era necessário ontem.

🤷‍♂️

Voltarei a relatar se encontrar algo sobre isso nos fóruns da Apple.

EDIT2: O Macbook da esposa ainda está no 10.14, e /bin/ls ~/Library/Mail não funciona com /bin/ls adicionado ao FDA, então parece que pode não ser algo novo no 10.14.1. 😕

Ainda trabalhando nisso.

Continua a ser muito doloroso, mas finalmente tenho uma solução alternativa que acho que funcionará para meus propósitos.

Eu detalhei o processo aqui , mas o resultado final é:

Você pode usar Script Editor.app para transformar um AppleScript em um pacote de aplicativos. Esse AppleScript pode executar seu script de backup restic (no meu caso /path/to/restic-backup.sh , onde restic-backup.sh é um script bash que executa restic com minhas configurações desejadas), e você pode adicionar o pacote de aplicativos resultante ao FDA em para obter acesso aos arquivos protegidos.

No entanto, isso torna difícil automatizar os backups em execução no nível do sistema. O comando interno open funciona, mas executa o aplicativo sob seu usuário -- assim, enquanto os arquivos protegidos pela FDA acima são copiados, você obterá erros de permissão em qualquer arquivo que seja apenas legível por root (por exemplo, root -propriedade 0600 coisas).

Minha solução neste momento é fazer com que o AppleScript chame o script de backup com sudo e dê ao meu usuário privilégios para executar esse script com privilégios de root sem uma senha ( sudo visudo , NOPASSWD: , etc).

Não é bonito, mas parece estar funcionando.

Gostaria de deixar isso em aberto para sugestões de usuários do MacOS com mais experiência. Se nada mais satisfatório surgir, eu poderia adicionar essa informação aos documentos (embora essa solução honestamente não pareça muito satisfatória).

Inacreditável, isso parece funcionar e é muito mais limpo e simples.

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

O binário resultante pode ser chown root e chmod 0700 , então adicionar ao Full Disk Access e parece funcionar. Ele pode então ser adicionado a uma plist /Library/LaunchDaemons para ser executado automaticamente.

As primeiras 2 execuções estão funcionando até agora, espero que isso não acabe como várias partidas falsas acima.

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

Minha corrida automatizada ontem à noite funcionou. Estou implantando essa estratégia no Macbook Air da minha esposa hoje, se parecer que funciona lá também, considerarei isso uma correção razoável e trabalharei em um pequeno PR para https://github.com/restic/restic. net (se isso parece razoável).

Oi @n8henrie , eu vim aqui depois de encontrar esse problema exato e encontrar sua postagem no blog. Obrigado por fazer toda essa pesquisa.

A solução acima (chamar script de shell do binário Go simples) não está funcionando para mim. Tem certeza de que está acessando com sucesso todos os seus arquivos?

Percebo em particular que stdout/stderr é descartado para /dev/null. Ele também não pode ler stdin se, por exemplo, restic quiser solicitar uma senha. (Também meio engraçado, por que seu bash é /usr/local/bin/bash e não /bin/bash ? Apenas curioso.)

De qualquer forma, fiz as seguintes alterações para ver a saída do erro:

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

Antes de ver sua postagem no blog, meu primeiro instinto foi adicionar o próprio binário restic ao FDA, e isso não funcionou para mim em 10.14.1 (18B75). Não sei por que inserir outro programa (o wrapper Go chamando um shell script, em última análise, chamando restic) mudaria alguma coisa.

Isso ainda está funcionando para você?

@n8henrie obrigado por nos manter informados! Você também pode escrever um post sobre isso no blog restic, se estiver disposto (além de uma pequena seção no manual ou algo assim) ... :)

@fd0 eu ficaria honrado!

@armhold sim, parece estar funcionando como um encanto, veja abaixo. No MBA da minha esposa, acho que precisei de uma reinicialização antes de começar a funcionar (mas não no meu). IIRC para ela, criei o binário, reiniciei, adicionei ao FDA e funcionou.

Antes da correção:

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

Após a correção:

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

A mesma correção também está funcionando no Macbook Air da minha esposa, ambos verificados no controle remoto com restic find '/Users/*/Library/Mail' --snapshot latest --host=$(hostname) (onde ~/Library/Mail é um dos diretórios geralmente protegidos, como pode ser visto no log de erros acima) .

Percebo em particular que stdout/stderr é descartado para /dev/null. Ele também não pode ler stdin se, por exemplo, restic quiser solicitar uma senha.

Isso vai depender inteiramente do seu script. Como você pode ver no meu post original, como minha configuração é totalmente automatizada, ela está configurada para ler a senha de um arquivo (0600 de propriedade do root), mas também pode ler de um envvar ou qualquer um dos métodos usuais. Você está certo, eu não acho que isso funcionará para coisas interativas. Ele também registra tudo em um arquivo: &>> /path/to/file.log .

(Também meio engraçado, por que seu bash é /usr/local/bin/bash e não /bin/bash? Apenas curioso.)

Eu uso o Homebrew para obter uma versão mais recente do 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.

Isso me traz recursos mais modernos, como o operador &>file.log (que economiza algumas teclas em comparação com 2>&1 >file.log .

Antes de ver sua postagem no blog, meu primeiro instinto foi adicionar o próprio binário restic ao FDA, e isso não funcionou para mim em 10.14.1 (18B75). Não sei por que inserir outro programa (o wrapper Go chamando um shell script, em última análise, chamando restic) mudaria alguma coisa.

Eu também não estou totalmente certo sobre isso. Para o meu caso de uso, tenho muitas outras configurações que faço no meu script bash (comando sftp um pouco complicado, onde o destino, os caminhos de backup e várias opções são baseados no nome do host), portanto, chamar o próprio binário restic não era uma opção. Posso experimentar um pouco.

Certo, obrigado pela explicação. Acabei de tentar reconstruir, reiniciar + adicionar FDA e ainda recebo operation not permitted . Também tentei mover o wrapper binário e o script de shell para /Applications e sem sorte. Vou continuar cavando.

Huh. Definitivamente não precisa estar em /Applications para mim.

Você está em 10.14 ou 10.14.1? Estou no último.

E você pode tentar usar o comando tccutil que mencionei para limpar todas as entradas de antemão.

Estou em 14.10.1 (18B75). Eu tentei o comando tccutil também, sem sorte. Eu entendo por que a Apple está fazendo isso, mas é realmente frustrante não ter um caminho claro sobre o que fazer aqui.

Huh. Isso é estranho.

Estranhamente, eu tentei e não consigo fazer o binário restic funcionar diretamente.

Não está claro por que isso não está funcionando, mas minha solução alternativa é (para mim).

Parece outro erro intermitente - acho que devemos adiar
documentação formal / redação até que possamos obter a de outra pessoa
computador trabalhando com o mesmo sistema. Eu sou 2 por 2, mas não vejo por que
isso não está funcionando para @armhold.

@armhold , você pode postar uma cópia do script bash exato e do código Go que você está
usando e como você está executando isso? Vou ver se consigo reproduzir do meu lado.

Estranhamente, eu tentei e não consigo fazer o binário restic funcionar diretamente.

Sim, é isso que eu não entendo. Não vejo por que o wrapper Go teria sucesso onde o próprio binário restic falharia. Algo parece errado.

você pode postar uma cópia exata do script bash e do código Go que está usando e como está executando-o?

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

• tanto o script shell quanto o wrapper go estão instalados no meu diretório ~/bin .
• adicionado ~/bin/restic-fda ao FDA via Preferências do Sistema
• Estou executando restic-fda de uma conta de usuário não root interativamente na linha de comando no Terminal. Recebo erros como: error: Open: open /Users/armhold/Library/Application Support/AddressBook: operation not permitted .
• executando como root (via sudo) falha da mesma forma

Eu não tentei executá-lo via launchctl.

Little Snitch, um firewall, faz algo semelhante - para conexões de saída, ele pergunta se o "Terminal via restic" faz a conexão (em vez de apenas restic); ou seja, Terminal.app sendo o principal para conceder permissão.

O que fiz no final foi agrupar meu script de shell como um aplicativo usando Platypus e conceder FDA para esse aplicativo gerado. Em seguida, inicie os backups via Finder. Funciona até agora.

launchctl será o próximo passo.

Para sua informação, isso ainda está funcionando para mim (incluindo após o MacOS mais recente
atualizar). Alguma novidade do @armhold?

Ainda não funciona para mim. Desisti e acabei de dar o Terminal FDA.

Infelizmente, estou perplexo novamente.

Estou em 14.10.2. Meu script de backup restic ainda está funcionando, sem erros de permissão em seus logs. No entanto, agora não consigo fazer com que o script de @armhold ou mesmo meus scripts de teste anteriores funcionem (que não fazem nada além de abrir o diretório protegido ~/Library/Mail ).

🤷‍♂️

Você já tentou executar seu wrapper (funcionando) em um novo repositório? O que quero dizer é, você tem certeza de que não está pulando arquivos antigos e, portanto, já presentes no repositório? Imagino que você ainda receba um erro ao tentar descer para as pastas protegidas, à medida que restic caminha pela árvore.

@mholt Qual é o status disso e da relica - você trabalhou de alguma forma e, em caso afirmativo, pode compartilhar conosco quais etapas você toma para fazer isso?

Depois de atualizar alguns clientes, estou vendo esse comportamento também, muito chato e difícil de lidar sem envolver coisas e mexer.

@rawtaz

Qual é o status disso e da relíquia - você trabalhou em torno disso de alguma forma e, em caso afirmativo, pode compartilhar conosco quais etapas você toma para fazer isso?

Eu só atualizei para o Mojave na semana passada. Mas instalei o Relica e consegui reproduzir o erro "operação não permitida" ao tentar fazer backup ~/Library/Mail.

Em seguida, adicionei Relica.app à tela do FDA e executei novamente o backup do Relica.

Ele fez backup com sucesso sem erros desta vez (enquanto o primeiro instantâneo feito por Relica+restic não mostrou a pasta Mail por causa do erro de permissão):

Então, temo não ter respostas para contribuir com este tópico. :-/ Não tenho certeza se vai _continuar_ funcionando, mas é claro que espero que sim.

Eu também decidi envolver meu script de backup restic em um pacote .app para poder fornecer FDA. É uma merda ter que fazer isso, mas parece ser o único caminho prático a seguir.

No começo, tentei dar apenas o FDA binário restic, mas isso não funcionou.
Eu também tentei dar meu script de backup (um script Bash que chama restic) FDA, mas isso também não funcionou.
Eu não tentei o wrapper do @armhold .

Eu usei Platypus como sugerido acima, e funciona muito bem. Ele produz um pacote .app que posso fornecer à FDA nas configurações do sistema do macOS, e isso resolve o problema.

A única desvantagem que notei durante o uso é que quando o .app é iniciado (para mim, é iniciado pelo crontab usando open -ga ~/Applications/Backup.app , a janela atual perde o foco. Isso pode ser um incômodo sério para meus usuários, mas é pelo menos temos backups funcionando novamente. Achei que o switch -g resolveria isso, mas infelizmente não muda nada.

Tentei rapidamente ver o que acontece quando você exclui o pacote .app (mova-o para a Lixeira, esvazie a lixeira) e o substitui por um novo pacote .app com o mesmo nome. Minhas observações são que quando você remove o antigo, a entrada no FDA nas preferências do sistema desaparece, mas quando você coloca o novo de volta no mesmo lugar, a entrada aparece novamente, indicando que o sistema reconhece e consideraria o novo .app ter FDA. No entanto, quando executei o novo aplicativo depois disso, obtive os erros originais de volta. Depois que removi a entrada do FDA para o aplicativo nas preferências do sistema e adicionei uma nova entrada do FDA para ele, os erros desapareceram novamente. Por enquanto, estou presumindo que, ao substituir o pacote .app, também preciso substituir a entrada do FDA para que funcione. Pode muito bem ser que, se alguém apenas substituir partes do pacote .app, ele continue funcionando. Isso precisa de mais investigação AFAICT.

Para quem quiser empacotar restic em um pacote .app, aqui está um tutorial um tanto genérico que escrevi alguns meses atrás sobre como fazer isso para qualquer programa Go, incluindo o código, se você quiser apenas alterar algumas configurações e estar no seu maneira: https://medium.com/@mattholt/packaging -a-go-application-for-macos-f7084b00f6b5

10.14.3 -- ainda não há boas notícias para rodar apenas com binário.

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

Funciona se Terminal.app for adicionado ao FDA, mas não apenas com ls (ou outros binários).

applescript/automator funciona, mas mostra um ícone no dock; alternativamente, usando xcode/swift cli, compile isso em um binário e adicione-o ao FDA (substitua /full/path/to por seus caminhos reais)

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 sem sorte aqui.

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

Recentemente comecei a usar o Restic e tenho tentado fazê-lo funcionar como um cron job chamado do root crontab sudo crontab -e para que eu pudesse me sentir um pouco mais seguro tendo meu script de backup em um arquivo acessível apenas com privilégios sudo . Eu estava recebendo exatamente os mesmos erros que @ n8henrie, mas agora tenho uma solução funcional e gostaria de saber se isso funciona para outras pessoas aqui.

Primeiro um pouco de fundo da minha configuração:

Eu tenho um script de backup em /Users/myuser/bin chamado restic-backup.sh com permissões 700 (somente root/sudo read/write/execute). Eu executo este arquivo com meu crontab root sudo crontab -e . Eu uso o iTerm como meu terminal padrão. Eu instalei restic e zsh com o Homebrew.

versão 10.14.5 do macOS

restic-backup.sh:

Meu arquivo de script de backup tem o seguinte.

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

Então, no meu arquivo crontab raiz: sudo crontab -e eu tenho:

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

Em acesso total ao disco:

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

Como @n8henrie , eu pensei que os programas que realmente acessam os arquivos como restic seriam os que exigem o FDA, mas parece que os programas que fazem o pedido inicial sudo precisam do FDA: cron na caixa automatizada e iTerm.app na caixa manual.

Descobri algo útil: ao colocar um aplicativo na lista de permissões, ele se aplica a qualquer script ou binário dentro do diretório do aplicativo. Portanto, você não precisa iniciar o aplicativo diretamente. Na verdade, o aplicativo em si é completamente irrelevante - ele simplesmente atua como um contêiner para a lista de permissões. Você pode copiar seu script para um aplicativo arbitrário, colocar esse aplicativo na lista de permissões e executar seu script. A única ressalva é que você precisa remover e adicionar novamente o aplicativo à lista de permissões toda vez que alterar seu script ou binário dentro dele.

@atticusmatticus @russelldavis -- Acho que uma das atualizações recentes do MacOS pode ter mudado algo novamente -- eu definitivamente tentei ambas as estratégias sem sorte. Mas eu também tentei o abaixo, que parou de funcionar, mas agora está funcionando novamente (mais ou 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. Adicione o binário gotest (e nada mais) ao Full Disk Access
3. copie o plist para ~/Library/LaunchAgents/
4. Carregue o daemon lançado: launchctl load -w ~/Library/LaunchAgents/com.me.gotest.plist

Agora, curiosamente, com o binário gotest , mas não launchd (ou launchctl ) adicionado ao FDA, ainda não consigo executar diretamente:

$ 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

Mas está rodando sem erros do daemon lançado (a cada 15 segundos conforme configurado), que não está rodando como root ( ~/Library/ not /Library/ e 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

Curiosamente, ainda estou vendo, incluindo uma reinicialização:

||ir binário no FDA|ir binário não no FDA
---|:---:|:---:
ir binário sem sudo |err|err
ir binário com sudo |err|err
launchd running go binary|RUNS|err

Resto não diretamente relacionado, mas ao problema do FDA.
Acho que tenho uma ideia de como provavelmente está funcionando e espero não ter sido o capitão óbvio. Eu ainda não consegui encontrar discussão, artigo ou documentação útil sobre.

A FDA funciona para aplicativos que foram incluídos na lista de permissões (abrir significa que eles são iniciados por launchd), para quaisquer processos filhos desses aplicativos, mesmo os não incluídos na lista de permissões, e para binários na lista de permissões, se forem lançados diretamente por launchd ( launchd.plist ou launchctl submit ). Não funciona se o binário na lista de permissões for iniciado em uma árvore de processos com aplicativo pai/binário não na lista de permissões.

A partir disso, parece que launchd é responsável pela árvore de processos da lista de permissões, dependendo do aplicativo/binário que foi incluído na lista de permissões.

A partir dos experimentos, parece que o caminho para o binário deve ser exato, portanto, a lista de permissões não será acionada se, para o binário da lista de permissões, o launchctl plist tiver WorkingDirectory especificado e o caminho relativo ./some-binary for usado, nem funcionará por /some/path/./some-binary ou /some/path/../path/some-binary , apenas /some/path/some-binary .
Também não é possível usar o aplicativo na lista de permissões para shebang mesmo se iniciar o script diretamente por launchd , então #!/some/path/some-binary não funcionará, apenas /some/path/some-binary /path/to/script .

Sim, eu corro de launchd . Algumas leituras interessantes aqui

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/

Acho que temos informações e pontos de dados suficientes para fornecer pelo menos algumas diretrizes (e talvez um link para esse problema) nos documentos, e gostaria de começar a trabalhar nisso, se estiver tudo bem.

Este deve ser um novo ponto em Exemplos , como a seção sobre como fazer backup sem executar como root no Linux ?

Pretendo observar que:

• O acesso total ao disco é necessário para fazer backup do máximo possível do disco
• Um script launchd executado como root pode chamar um binário que está na lista de permissões da FDA sem precisar adicionar launchd à FDA
• A menos que Terminal.app esteja listado no FDA, o binário não pode acessar o disco completo quando chamado do Terminal
• Se o Terminal.app estiver listado no FDA, ele poderá acessar o disco completo quando chamar um binário, esteja ou não esse binário no FDA

Isso soa como se refletisse a compreensão e a experiência de todos?

Embora um pouco complicado, fiquei satisfeito com minha configuração em execução em 2 Macbooks nos últimos 1 ano e provavelmente incluiria partes dela como exemplo. Minha configuração é:

• Eu tenho um script de shell que executa um comando restic específico da máquina com base em várias variáveis ​​de ambiente (o mesmo script também é executado em 4 computadores Linux, que chamam esse script diretamente).
• Em meus computadores MacOS, construo um binário que basicamente executa o script de shell acima. Eu uso um script de shell aqui para fácil configuração / atualizações / controle de versão, embora isso também possa ser feito facilmente em Go diretamente.
• Este binário é adicionado ao FDA
• Eu corro um daemon launchd em todo o sistema (que é executado com permissões de root) para iniciar este binário em um cronograma

Usar um binário semelhante a https://github.com/restic/restic/issues/2051#issuecomment -442872479 está funcionando para mim. Eu fui com c porque eu não tenho ir instalado agora. Para outros copiar/colar:

1. backup.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. whitelist o binário de backup e use-o como quiser

Curiosamente, ainda estou vendo, incluindo uma reinicialização:

ir binário no FDA ir binário não no FDA
ir binário sem sudo err err
ir binário com sudo err err
launchd running vai binário RUNS err

Obrigado!

A solução para mim foi criar um arquivo .plist que chama restic diretamente e colocar todos os parâmetros dentro ou em arquivos separados, usando as opções -p, --exclude-files, --files-from. E, claro, dê permissões binárias restic do 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>

Como descobrir qual aplicativo deve ser adicionado ao FDA? Em suma, encontre o aplicativo que o executa.

Você pode manter o processo em execução e percorrer o pid pai do processo até que o pid ancestral seja 1, iniciado via ps ajx ou ps ao pid,ppid,command com grep .

E resumindo:

• executado via crontab, /usr/sbin/cron , obsoleto por launchd.plist
• executado via launchd.plist, o binário em Program ou ProgramArguments
• execute no Terminal, Terminal.app
• executado via ssh, /usr/libexec/sshd-keygen-wrapper ou similar
• execute através de outro aplicativo, encontre-o.

Então, para @n8henrie , você precisa encontrar o binário real.

Outra maneira de resolver isso se você estiver executando coisas via launchd: LaunchControl agora vem com um auxiliar chamado fdautil que você pode colocar na lista de permissões e, em seguida, executar comandos usando fdautil exec . Ele só permitirá comandos que você colocou na lista de permissões via LaunchControl ou fdautil set .

Há um pouco de informação sobre isso em https://www.soma-zone.com/LaunchControl/FAQ.html e mais detalhes na janela de ajuda do aplicativo.