Restic: MacOS Mojave: kesalahan: Buka: ... operasi tidak diizinkan

Dibuat pada 17 Okt 2018  ·  56Komentar  ·  Sumber: restic/restic

Fitur privasi MacOS Mojave tampaknya membatasi akses restic ke file (setidaknya apa yang tampaknya terjadi), saya mendapatkan kesalahan izin yang tidak saya dapatkan sebelum memutakhirkan.

Mac OS 10.14

Menjalankan dengan sudo:

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

... banyak file lainnya.

Keluaran restic version

0.9.2 (terbaru di homebrew)

Bagaimana tepatnya Anda menjalankan restic?

Skrip bash yang sama yang telah saya gunakan selama berbulan-bulan sebelum memutakhirkan ke Mojave, dijalankan dengan hak akses root.

RESTIC_PASSWORD_FILE="/path/to/file.txt" \
HOME="/path/to/homedir" \
/usr/local/bin/restic \
    --repo sftp:myserver.local:my/repo/path \
    --option='sftp.command=ssh -p REDACTEDPORT -i REDACTEDKEYFILE -o identitiesonly=yes -l restic myserver.local -s sftp' \
    --exclude-file="${DIR}/global-exclude.txt" \
    --exclude-if-present='.norestic' \
    backup \
    --cleanup-cache \
    / \
    &>> /path/to/file.log

Backend/server/layanan apa yang Anda gunakan untuk menyimpan repositori?

sftp, seperti di atas. repo yang sama seperti sebelumnya.

Perilaku yang diharapkan

Mudah-mudahan membaca dan mencadangkan semua file saat dijalankan sebagai root (menyadari ini mungkin bukan masalah restic, tapi sepertinya itu pasti masalah untuk backup).

Perilaku sebenarnya

sesuai di atas

Langkah-langkah untuk mereproduksi perilaku

sudo bash restic-backup.sh (skrip di atas)

Apakah Anda tahu apa yang mungkin menyebabkan ini?

Tebakanku:

Apakah Anda punya ide bagaimana memecahkan masalah?

Tidak. Apa yang saya coba sejauh ini:

  • Tidak ada libcap di MacOS, jadi tidak dapat menggunakan setcap .
  • Mencoba menambahkan restic ke "Full Disk Access" di System Preferences baru -> panel Keamanan dan Privasi, tidak berhasil.

Apakah restic membantu Anda atau membuat Anda bahagia dengan cara apa pun?

Setelah bertahun-tahun mencoba menemukan solusi pencadangan sumber terbuka yang baik, andal, skrip, dan terbuka, ini adalah satu-satunya yang sesuai dengan tagihan. Sangat bersyukur!

backup documentation wanted darwin discussion

Komentar yang paling membantu

Saya baru-baru ini mulai menggunakan Restic dan telah mencoba membuatnya berfungsi sebagai tugas cron yang dipanggil dari root crontab sudo crontab -e sehingga saya bisa merasa sedikit lebih aman memiliki skrip cadangan saya dalam file yang hanya dapat diakses dengan hak sudo . Saya mendapatkan kesalahan yang sama persis dengan @ n8henrie tetapi sekarang saya memiliki solusi yang berfungsi dan ingin tahu apakah ini berfungsi untuk orang lain di sini.

Pertama, sedikit latar belakang pengaturan saya:

Saya memiliki skrip cadangan di /Users/myuser/bin bernama restic-backup.sh dengan izin 700 (hanya root/Sudo read/write/execute). Saya menjalankan file ini dengan root crontab saya sudo crontab -e . Saya menggunakan iTerm sebagai terminal default saya. Saya telah menginstal restic dan zsh dengan Homebrew.

macOS versi 10.14.5

restic-backup.sh:

File skrip cadangan saya memiliki yang berikut di dalamnya.

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

Kemudian di file crontab root saya: sudo crontab -e Saya punya:

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

Dalam Akses Disk Penuh:

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

Seperti @n8henrie , saya pikir program yang benar-benar mengakses file seperti restic akan menjadi program yang memerlukan FDA tetapi tampaknya program yang membuat permintaan sudo awal membutuhkan FDA: cron dalam kasus otomatis, dan iTerm.app dalam kasus manual.

Semua 56 komentar

Ya, tampaknya Anda harus melakukan Akses Disk Penuh: https://www.backblaze.com/blog/mojave-permissions/

Apakah Anda _yakin_ Anda menambahkan biner restic yang tepat? Apakah Anda memindahkan file atau mengubah atributnya (kepemilikan, dll) setelah menambahkannya ke Akses Disk Penuh di System Preferences?

(Saya punya Mac, tapi saya belum punya Mojave, maaf.)

Saya menggunakan homebrew, jadi pertama-tama saya menambahkan /usr/local/bin/restic ke Akses Disk Penuh, memulai pekerjaan, mencatat kesalahan yang sama, jadi saya menghapusnya dan menambahkan jalur ke biner yang sebenarnya (mencatat bahwa ini sayangnya harus redone setiap kali pembaruan restic): /usr/local/Cellar/restic/0.9.2/bin/restic , sayangnya saya melihat kesalahan yang sama.

Tidak ada perubahan, menambahkan biner ke Akses Disk Penuh, beralih kembali ke terminal dan menjalankan sudo myscript.sh , yang berfungsi untuk sebagian besar file tetapi memberikan kesalahan izin pada yang lain.

Catatan sampingan, ada masalah lain (mungkin terkait Mojave) yang saya coba selesaikan, di mana otentikasi sftp pubkey saya berhenti berfungsi saat dijalankan dari launchctl (sebagai root), tetapi berfungsi saat dijalankan secara manual sebagai root, tapi saya akan ajukan masalah baru jika saya dapat menentukan bahwa itu tidak spesifik untuk pengaturan saya.

Menarik. Apa yang terjadi jika Anda menjalankan restic secara langsung? Dan/atau tambahkan skrip Anda ke FDA. Hanya memotret dalam kegelapan di sini, jujur. Jika saya punya Mojave, saya akan mencobanya.

Pemikiran yang bagus.

Skrip saya sendiri tidak dapat dieksekusi (tanpa alasan yang bagus), seperti yang dicatat saya menjalankannya dengan sudo bash myscript.sh ( /usr/local/bin/bash sebenarnya); itu tidak dapat ditambahkan ke FDA karena tidak dapat dieksekusi.

Saya mencoba menambahkan /usr/local/bin/bash ke FDA dan tidak ada dadu.

EDIT: Rupanya saya salah, bahkan setelah chmod +x , backup.sh saya masih tidak dapat ditambahkan langsung ke FDA (sementara binari bash dan restic bisa). Aneh.

EDIT2: Untuk lebih teliti, saya menambahkan binari bash dan restic keduanya ke FDA dan saya melihat kesalahan yang sama.

Mungkin masalah yang lebih besar daripada restic -- Saya bahkan mencoba menambahkan /bin/ls ke daftar FDA dan masih mendapatkan kesalahan.

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

EDIT: Solusi buruk: tambahkan Terminal.app ke izin FDA dan kesalahan izin hilang.

Mencoba codesign dalam biner restic dan skrip backup.sh saya dan menambahkan ke FDA, tidak berhasil.

(Setelah membaca beberapa utas itu) Ya ampun. Ini sangat menjengkelkan. Terima kasih telah memeriksanya! Saya akan terus menyelidiki juga setelah saya meningkatkan ...

Wow, terima kasih banyak atas informasinya dan semua waktu yang Anda habiskan untuk masalah ini! Saya tidak memiliki mac sama sekali, jadi saya senang jika Anda berdua dapat mengetahuinya dan kami dapat mendokumentasikan masalah ini untuk pengguna lain! Terima kasih lagi!

@mholt Jika Anda mau, Anda dapat menginstal uji coba VMware Fusion selama 30 hari dan menginstal Mojave di dalamnya (kecuali Apple melumpuhkan kemampuan untuk menginstalnya secara ad-hoc). Uji coba itu tidak menimbulkan polusi dan dapat dihapus jika Anda tidak menginginkannya nanti.

Saya mencatat di atas bahwa menambahkan Terminal.app ke System Preferences -> Security & Privacy -> Full Disk Access daftar adalah solusi, karena ketika saya menjalankan skrip saya secara manual ( sudo /usr/local/bin/bash mybackup.sh ) sepertinya berfungsi tanpa kesalahan izin.

Untuk beberapa alasan, ketika saya memeriksa log saya pagi ini dari menjalankan restic semalam otomatis (berdasarkan skrip launchd pada /Library/LaunchDaemons/com.n8henrie.restic.plist yang berjalan setiap malam dengan hak akses root), kesalahan izin masih ada.

Dan sayangnya, saya sekarang tidak bisa mendapatkan solusi untuk bekerja -- bahkan dengan Terminal.app di FDA, saya masih mendapatkan kesalahan izin ketika saya menjalankan sudo launchctl start com.n8henrie.restic atau sudo /usr/local/bin/bash mybackup.sh .

Jadi solusinya sepertinya tidak berhasil, atau ada sesuatu yang berubah.

EDIT: Gah, baru saja menambahkan semua 3 ke FDA -- Terminal.app , /usr/local/bin/bash , dan /usr/local/Cellar/restic/0.9.2/bin/restic -- dan sekarang berjalan tanpa kesalahan. ️

FWIW, ini adalah output log saya , yang berisi daftar file yang mendapatkan kesalahan. Seperti yang Anda lihat, ada beberapa masalah besar, seperti perpustakaan foto saya.

@n8henrie Dari utas dukungan Mac yang Anda tautkan sebelumnya, tampaknya FDA mengharuskan aplikasi yang disetujui untuk menjadi .app bundle terdaftar di folder Aplikasi, yang mungkin menjadi alasan mengapa Terminal.app berhasil... tetapi Anda harus menambahkan ketiganya ke FDA dalam kasus Anda? Menarik...

@mholt sepertinya ada hal lain yang terjadi. Saya meninggalkan pengaturan saya persis seperti kemarin (semua 3 di FDA, yang tidak menghasilkan kesalahan izin), dan operasi semalam saya masih mendapatkan kesalahan izin lama yang sama.

Ini telah terjadi dua kali sekarang, di mana setelah mengutak-atik beberapa saat saya berjalan tanpa kesalahan izin yang kemudian muncul kembali. Apakah restic entah bagaimana tahu apakah suatu file telah berubah atau tidak tanpa perlu membuka file - semacam cache? Saya ingin tahu apakah saya tertipu oleh proses yang dilakukan bersama-sama, dan tidak ada perubahan sementara pada file dan oleh karena itu restic tidak mencoba membukanya?

Kalau tidak, saya kesulitan menjelaskan apa yang terjadi di sini.

Pertanyaan bagus. Saya tahu restic menggunakan cache tetapi saya belum melihat seberapa agresif ia mematuhinya jika terjadi kesalahan izin, dll.

Pertanyaan bagus. Saya tahu restic menggunakan cache tetapi saya belum melihat seberapa agresif ia mematuhinya jika terjadi kesalahan izin, dll.

Tidak semuanya. Cache hanya berisi file dari repo, tidak ada informasi tentang sistem file (yang tidak ada dalam repo) yang disertakan.

Oke -- ya, menurut saya ini bukan bug di restic. Ini jelas merupakan masalah macOS Mojave yang, pada titik ini, saya cukup yakin restic sendiri tidak dapat melakukan apa pun untuk memperbaikinya.

Keren, terima kasih atas umpan baliknya, saya menutup masalah ini untuk saat ini. Silakan tambahkan lebih banyak komentar jika Anda menemukan sesuatu. Terima kasih!

Saya sedikit terkejut melihat masalah sudah selesai -- ini sepertinya a
ketidakcocokan utama dengan platform utama, dan menutupnya pada saat ini
mungkin membuatnya "tidak terlihat, tidak terpikirkan".

Saya mengerti bahwa ini bukan masalah restic, tapi sepertinya
ada beberapa langkah wajar yang dapat diambil untuk pengguna MacOS. Dengan adanya,
kemampuan pengguna untuk mencadangkan sebagian besar data pribadi mereka yang paling penting
data (misalnya foto) dikompromikan secara default pada versi saat ini
MacOS. Itu sepertinya masalah besar bagi saya, untuk perangkat lunak cadangan apa pun!

Beberapa saran/kemungkinan (yang dengan senang hati saya bantu kerjakan):

  • Kemungkinan untuk memperbaiki masalah

    • Apakah mungkin untuk menyediakan aplikasi pembungkus MacOS yang tepat yang

      dapat ditambahkan ke daftar FDA, yang berisi biner restic

    • Jika dapat mengetahui cara melakukan hal di atas, alih-alih memberikan

      aplikasi, bisakah kami menyertakan instruksi tentang bagaimana pengguna dapat menyelesaikannya?

      sendiri dengan semacam Makefile atau XCode?

  • Solusi

    • Berikan info di dokumen tentang binari paling aman / minimal

      yang perlu ditambahkan ke FDA

    • Berikan tautan ke info tentang (dan risiko) penonaktifan SIP

  • Peringatan

    • Sertakan info di dokumen di suatu tempat yang tidak akan dimiliki pengguna Mojave

      data mereka dicadangkan sepenuhnya secara default

Secara keseluruhan, situasinya tampaknya tidak terlalu berbeda dengan cadangan penuh tanpa root
di Linux, dengan menonaktifkan SIP sama sekali seperti menjalankan sebagai
root, dan menentukan serta merekomendasikan kompromi yang cukup aman dengan
FDA menjadi sesuatu seperti menggunakan setcap .

Sayangnya Macbook saya ada di toko minggu ini jadi saya tidak bisa
kerjakan salah satu dari ini segera, tetapi saya akan tertarik untuk mendengar pemikirannya
dari orang lain; mungkin saya jauh dari dasar, atau mungkin tidak mengetahui secara spesifik
alur kerja tim yang tenang untuk mengelola masalah.

Beberapa pembaruan lagi sekarang setelah saya mendapatkan kembali mesin saya:

Saya tidak dapat meniru keberhasilan saya di atas dalam mendapatkan cadangan sistem lengkap dari skrip launchd saya.

Saya sudah mencoba menambahkan semua di bawah ini ke daftar FDA (pada saat yang sama), dan masih mendapatkan kesalahan:

  • istirahat
  • pesta
  • peluncuranctl
  • peluncuran
  • Terminal.app

Hanya untuk eksperimen, binari telanjang tampaknya berfungsi dengan baik ketika ditambahkan ke daftar FDA dan tampaknya tidak ada hubungannya dengan desain bersama. Bandingkan binari ls yang disediakan oleh MacOS dan 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

Sebelum dan menambahkan ke daftar 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

Selain itu, mereka berfungsi dengan baik ketika dimasukkan ke dalam skrip bash selama ls ada di FDA (tidak perlu menambahkan bash secara terpisah), yang membuat saya berpikir saya hanya perlu menambahkan restic .

Juga, untuk perbandingan menjalankan kesalahan skrip Go berikut jika tidak di FDA, tetapi berfungsi dengan baik dengan sendirinya serta ketika dipanggil dari launchd selama biner ada di FDA (tidak perlu menambahkan launchd / launchctl / apa pun).

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

Keluaran:

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

Selanjutnya saya akan melakukan beberapa percobaan dengan Restic untuk melihat apakah saya dapat mengetahui mengapa itu mendapatkan kesalahan izin bahkan ketika ditambahkan ke FDA (walaupun binari lain tampaknya berfungsi setelah ditambahkan).

Oke, terima kasih atas umpan baliknya! Saya akan membuka kembali masalah ini, mungkin kita bisa mencari tahu apa yang terjadi dan kemudian menambahkan beberapa dokumentasi ke manual.

~Masih mendapatkan Open kesalahan pada repo baru, dengan restic ditambahkan ke daftar FDA.~

Lihat editan di bawah.

$ 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

screenshot 2018-11-04 at 11 32 18 am

EDIT: Abaikan komentar ini -- Saya masih diganggu oleh kesalahan intermiten yang mengacaukan kemajuan apa pun, mungkin terkait dengan pembaruan ke MacOS 10.14.1 kemarin. Hari ini, kode Go yang sama dari kemarin yang secara konsisten bekerja dengan FDA dan gagal tanpanya (saya mengaktifkan dan menonaktifkannya beberapa kali untuk memastikan) tidak lagi berfungsi bahkan dengan FDA . Sama dengan ls .

Itu berfungsi jika Terminal.app ditambahkan ke FDA (sebagai satu-satunya entri), yang tidak diperlukan kemarin.

Saya akan melaporkan kembali jika saya dapat menemukan sesuatu tentang ini di forum Apple.

EDIT2: Macbook Istri masih di 10.14, dan /bin/ls ~/Library/Mail tidak berfungsi dengan /bin/ls ditambahkan ke FDA, jadi sepertinya itu bukan sesuatu yang baru di 10.14.1. 😕.

Masih mengerjakan ini.

Ini terus menjadi sangat menyakitkan, tetapi saya akhirnya memiliki solusi yang menurut saya akan berhasil untuk tujuan saya.

Saya telah merinci prosesnya di sini , tetapi intinya adalah:

Anda dapat menggunakan Script Editor.app untuk membuat AppleScript menjadi bundel aplikasi. Bahwa AppleScript dapat menjalankan skrip cadangan restic Anda (dalam kasus saya /path/to/restic-backup.sh , di mana restic-backup.sh adalah skrip bash yang menjalankan restic dengan pengaturan yang saya inginkan), dan Anda dapat menambahkan bundel aplikasi yang dihasilkan ke FDA di untuk mendapatkan akses ke file yang dilindungi.

Namun, ini menyulitkan untuk mengotomatiskan pencadangan yang berjalan pada tingkat sistem. Perintah open bawaan berfungsi, tetapi menjalankan aplikasi di bawah pengguna Anda -- jadi sementara file yang dilindungi FDA di atas dicadangkan, Anda akan mendapatkan kesalahan izin pada file apa pun yang hanya dapat dibaca root (mis. -memiliki 0600 barang).

Solusi saya saat ini adalah meminta AppleScript memanggil skrip cadangan dengan sudo dan memberikan hak istimewa kepada pengguna saya untuk menjalankan skrip itu dengan hak akses root tanpa kata sandi ( sudo visudo , NOPASSWD: , dll.).

Itu tidak cantik, tetapi tampaknya berhasil.

Saya ingin membiarkan ini terbuka untuk saran apa pun dari pengguna MacOS dengan lebih banyak keahlian. Jika tidak ada yang lebih memuaskan muncul, saya dapat menambahkan info ini ke dokumen (walaupun solusi ini sejujurnya tampaknya tidak terlalu memuaskan).

Luar biasa, ini tampaknya berhasil dan jauh lebih bersih dan lebih sederhana.

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

Biner yang dihasilkan dapat berupa chown root dan chmod 0700 , lalu tambahkan ke Akses Disk Penuh, dan tampaknya berfungsi. Kemudian dapat ditambahkan ke daftar /Library/LaunchDaemons untuk berjalan secara otomatis.

2 putaran pertama berhasil sejauh ini, saya harap ini tidak berakhir seperti beberapa awal yang salah di atas.

Jalan otomatis saya tadi malam berhasil. Saya menerapkan strategi ini ke Macbook Air istri saya hari ini, jika sepertinya berhasil di sana juga, saya akan menganggap ini sebagai perbaikan yang masuk akal dan mengerjakan PR kecil ke https://github.com/restic/restic. bersih (jika itu tampaknya masuk akal).

Hai @n8henrie , saya datang ke sini setelah menemukan masalah yang tepat ini dan kemudian menemukan posting blog Anda. Terima kasih telah melakukan semua penelitian ini.

Solusi di atas (panggil skrip Shell dari biner Go sederhana) tidak berfungsi untuk saya. Apakah Anda yakin berhasil mengakses semua file Anda?

Saya perhatikan secara khusus bahwa stdout/stderr dibuang ke /dev/null. Itu juga tidak dapat membaca stdin jika, misalnya, restic ingin meminta kata sandi. (Juga agak lucu, mengapa bash Anda /usr/local/bin/bash dan bukan /bin/bash ? Hanya ingin tahu.)

Bagaimanapun saya membuat perubahan berikut untuk melihat output kesalahan:

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

Sebelum melihat posting blog Anda, naluri pertama saya adalah menambahkan biner restic itu sendiri ke FDA, dan itu tidak berhasil untuk saya di bawah 10.14.1 (18B75). Saya tidak yakin mengapa memasukkan program lain (pembungkus Go memanggil skrip Shell, akhirnya memanggil restic) akan mengubah apa pun.

Apakah ini masih bekerja untuk Anda?

@ n8henrie terima kasih telah membuat kami tetap diposting! Anda juga bisa menulis posting blog tentang itu di blog restic jika Anda mau (selain bagian kecil di manual atau lebih)... :)

@ fd0 Saya akan merasa terhormat!

@armhold ya, sepertinya berfungsi seperti pesona, lihat di bawah. Pada MBA istri saya, saya pikir saya memerlukan reboot sebelum mulai bekerja (bukan milik saya). IIRC untuk miliknya, saya membuat biner, lalu reboot, lalu ditambahkan ke FDA, dan berhasil.

Sebelum perbaikan:

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

Setelah perbaikan:

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

Perbaikan yang sama juga bekerja pada Macbook Air istri saya, keduanya diverifikasi pada remote dengan restic find '/Users/*/Library/Mail' --snapshot latest --host=$(hostname) (di mana ~/Library/Mail adalah salah satu direktori yang biasanya dilindungi, seperti yang dapat dilihat pada log kesalahan di atas) .

Saya perhatikan secara khusus bahwa stdout/stderr dibuang ke /dev/null. Itu juga tidak dapat membaca stdin jika, misalnya, restic ingin meminta kata sandi.

Ini akan bergantung sepenuhnya pada skrip Anda. Seperti yang Anda lihat di posting asli saya, karena pengaturan saya sepenuhnya otomatis, itu diatur untuk membaca kata sandi dari file (root-milik 0600), tetapi juga bisa membaca dari envvar atau metode biasa. Anda benar, saya rasa ini tidak akan berhasil untuk hal-hal interaktif. Itu juga mencatat semuanya ke file: &>> /path/to/file.log .

(Juga agak lucu, mengapa bash Anda /usr/local/bin/bash dan bukan /bin/bash? Hanya ingin tahu.)

Saya menggunakan Homebrew untuk mendapatkan versi bash yang lebih baru

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

Ini memberi saya lebih banyak fitur modern, seperti operator &>file.log (yang menghemat beberapa penekanan tombol dibandingkan dengan 2>&1 >file.log .

Sebelum melihat posting blog Anda, naluri pertama saya adalah menambahkan biner restic itu sendiri ke FDA, dan itu tidak berhasil untuk saya di bawah 10.14.1 (18B75). Saya tidak yakin mengapa memasukkan program lain (pembungkus Go memanggil skrip Shell, akhirnya memanggil restic) akan mengubah apa pun.

Saya juga tidak sepenuhnya yakin tentang ini. Untuk kasus penggunaan saya, saya memiliki banyak pengaturan lain yang saya lakukan di skrip bash saya (perintah sftp yang agak rumit di mana tujuan, jalur cadangan, dan beberapa opsi didasarkan pada nama host) jadi memanggil biner restic itu sendiri tidak sebuah pilihan. Saya bisa bereksperimen dengannya sedikit.

Oke, terima kasih atas penjelasannya. Saya baru saja mencoba membangun kembali, me-reboot + menambahkan FDA, dan saya masih mendapatkan operation not permitted . Juga mencoba memindahkan pembungkus biner dan skrip Shell ke/Aplikasi, dan tidak berhasil. Saya akan terus menggali.

Hah. Jelas tidak perlu ada di /Applications untuk saya.

Apakah Anda menggunakan 10.14 atau 10.14.1? Aku di yang terakhir.

Dan Anda dapat mencoba menggunakan perintah tccutil yang saya rujuk untuk menghapus semua entri sebelumnya.

Saya menggunakan 10.14.1 (18B75). Saya mencoba perintah tccutil juga, tidak berhasil. Saya mengerti mengapa Apple melakukan ini, tetapi sungguh membuat frustrasi karena tidak memiliki jalur yang jelas tentang apa yang harus dilakukan di sini.

Hah. Ini aneh.

Anehnya, saya mencoba dan saya tidak bisa membuat biner restic bekerja secara langsung.

Tidak jelas mengapa ini tidak berhasil tetapi solusi saya adalah (untuk saya).

Sepertinya kesalahan intermiten lainnya -- saya pikir kita harus menunda
dokumentasi/tulisan formal sampai kita bisa mendapatkan milik orang lain
komputer yang bekerja dengan sistem yang sama. Saya 2 untuk 2, tapi saya tidak mengerti mengapa
ini tidak berfungsi untuk @armhold.

@armhold , dapatkah Anda memposting salinan skrip bash yang tepat dan kode Go Anda?
menggunakan dan bagaimana Anda menjalankannya? Saya akan melihat apakah saya dapat mereproduksi di pihak saya.

Anehnya, saya mencoba dan saya tidak bisa membuat biner restic bekerja secara langsung.

Ya, itu yang saya tidak mengerti. Saya tidak mengerti mengapa pembungkus Go akan berhasil di mana biner restic itu sendiri akan gagal. Sesuatu tampaknya tidak aktif.

dapatkah Anda memposting salinan skrip bash dan kode Go yang tepat yang Anda gunakan dan bagaimana Anda menjalankannya?

Tentu, ini dia: https://github.com/armhold/restic-fda.

  • skrip shell dan go wrapper diinstal di direktori ~/bin saya.
  • menambahkan ~/bin/restic-fda ke FDA melalui System Preferences
  • Saya menjalankan restic-fda dari akun pengguna non-root secara interaktif pada baris perintah di Terminal. Saya mendapatkan kesalahan seperti: error: Open: open /Users/armhold/Library/Application Support/AddressBook: operation not permitted .
  • berjalan sebagai root (via Sudo) gagal dengan cara yang sama

Saya belum mencoba menjalankannya melalui launchctl.

Little Snitch, firewall, melakukan hal serupa - untuk koneksi keluar, ia akan menanyakan apakah mengizinkan "Terminal via restic" membuat koneksi (bukan hanya restic); yaitu Terminal.app menjadi yang utama untuk memberikan izin.

Apa yang saya lakukan pada akhirnya adalah menggabungkan skrip shell saya sebagai aplikasi menggunakan Platypus , dan memberikan FDA ke aplikasi yang dihasilkan itu. Kemudian luncurkan pencadangan melalui Finder. Bekerja sejauh ini.

launchctl akan menjadi langkah selanjutnya.

FYI ini masih berfungsi untuk saya (termasuk setelah MacOS terbaru
memperbarui). Ada kabar dari @armhold?

Masih tidak bekerja untuk saya. Saya menyerah dan hanya memberi Terminal FDA.

Sayangnya, saya bingung lagi.

saya di 10.14.2. Skrip cadangan restic saya masih berfungsi, tidak ada kesalahan izin di lognya. Namun, saya sekarang tidak dapat membuat skrip @armhold atau bahkan skrip pengujian saya sebelumnya berfungsi (yang tidak melakukan apa pun selain membuka direktori yang dilindungi ~/Library/Mail ).

Sudahkah Anda mencoba menjalankan pembungkus (berfungsi) Anda pada repo baru? Maksud saya adalah, apakah Anda yakin itu tidak melewatkan file yang sudah lama, dan karena itu sudah ada di repo? Saya membayangkan Anda masih akan mendapatkan kesalahan saat mencoba turun ke folder yang dilindungi, saat restic berjalan di atas pohon.

@mholt Apa status ini dan peninggalan - apakah Anda telah mengatasinya, dan jika demikian, dapatkah Anda berbagi dengan kami langkah apa yang Anda ambil untuk melakukannya?

Setelah memutakhirkan beberapa klien, saya juga melihat perilaku ini, sangat menjengkelkan dan sulit ditangani tanpa membungkus barang dan mengotak-atik.

@rawtaz

Apa status ini dan relica - apakah Anda pernah mengatasinya, dan jika demikian, dapatkah Anda berbagi dengan kami langkah apa yang Anda ambil untuk melakukannya?

Saya sendiri baru saja memutakhirkan ke Mojave minggu lalu. Tetapi saya menginstal Relica dan dapat mereproduksi kesalahan "operasi tidak diizinkan" ketika mencoba mencadangkan ~/Library/Mail.

Saya kemudian menambahkan Relica.app ke layar FDA dan menjalankan kembali cadangan Relica.

screen shot 2018-12-27 at 1 54 49 pm

Ini berhasil dicadangkan tanpa kesalahan kali ini (sedangkan snapshot pertama yang dibuat oleh Relica+restic tidak menampilkan folder Mail sama sekali karena kesalahan izin):

screen shot 2018-12-27 at 1 51 31 pm

Jadi saya khawatir saya tidak punya jawaban untuk berkontribusi pada utas ini. :-/ Saya tidak yakin apakah itu akan _tetap_ bekerja tetapi tentu saja saya harap itu berhasil.

Saya juga memutuskan untuk membungkus skrip cadangan restic saya dalam bundel .app untuk dapat memberikannya FDA. Menyebalkan harus melakukan ini, tetapi tampaknya itu satu-satunya cara praktis ke depan.

Pada awalnya saya mencoba memberikan FDA biner restic saja, tetapi itu tidak berhasil.
Saya juga mencoba memberikan skrip cadangan saya (skrip Bash yang memanggil restic) FDA, tetapi itu juga tidak berhasil.
Saya tidak mencoba pembungkus @armhold .

Saya menggunakan Platypus seperti yang disarankan di atas, dan itu berfungsi dengan baik. Ini menghasilkan bundel .app yang kemudian dapat saya berikan FDA dalam pengaturan sistem macOS, dan ini menyelesaikan masalah.

Satu-satunya downside yang saya perhatikan selama penggunaan adalah ketika .app dimulai (bagi saya ini dimulai oleh crontab menggunakan open -ga ~/Applications/Backup.app , jendela saat ini kehilangan fokus. Ini bisa menjadi gangguan serius bagi pengguna saya, tetapi ini apa itu. Setidaknya kami memiliki cadangan yang berfungsi lagi. Saya pikir sakelar -g akan menanganinya, tetapi sayangnya itu tidak mengubah apa pun.

Saya secara singkat mencoba melihat apa yang terjadi ketika Anda menghapus .app bundle (memindahkannya ke Sampah, mengosongkan sampah) dan menggantinya dengan .app bundle baru yang memiliki nama yang sama. Pengamatan saya adalah bahwa ketika Anda menghapus yang lama, entri di FDA dalam preferensi sistem menghilang, tetapi ketika Anda meletakkan yang baru kembali di tempat yang sama, entri muncul lagi, menunjukkan bahwa sistem mengenali dan akan mempertimbangkan .app baru memiliki FDA. Namun, ketika saya menjalankan aplikasi baru setelah itu, saya mendapatkan kembali kesalahan asli. Setelah saya menghapus entri FDA untuk aplikasi di preferensi sistem dan menambahkan entri FDA baru untuk itu, kesalahan hilang lagi. Jadi untuk saat ini, saya berasumsi bahwa saat mengganti .app bundle, saya juga perlu mengganti entri FDA, agar bisa berfungsi. Mungkin saja jika seseorang hanya mengganti bagian dari .app bundle, itu akan tetap berfungsi. Ini perlu penyelidikan lebih lanjut AFAICT.

Bagi siapa saja yang ingin menggabungkan restic menjadi .app bundle, berikut adalah tutorial umum yang saya tulis beberapa bulan yang lalu tentang cara melakukannya untuk program Go apa pun, termasuk kode jika Anda hanya ingin mengubah beberapa pengaturan dan berada di cara: https://medium.com/@mattholt/packaging -a-go-application-for-macos-f7084b00f6b5

10.14.3 -- masih belum ada kabar baik untuk menjalankan dengan biner saja.

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

Berfungsi jika Terminal.app ditambahkan ke FDA, tetapi tidak hanya dengan ls (atau binari lainnya).

applescript/automator berfungsi tetapi menampilkan ikon di dok; sebagai alternatif, menggunakan xcode/swift cli, kompilasi ini menjadi biner dan tambahkan itu ke FDA (ganti /full/path/to dengan jalur asli Anda)

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 tidak beruntung di sini.

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

Saya baru-baru ini mulai menggunakan Restic dan telah mencoba membuatnya berfungsi sebagai tugas cron yang dipanggil dari root crontab sudo crontab -e sehingga saya bisa merasa sedikit lebih aman memiliki skrip cadangan saya dalam file yang hanya dapat diakses dengan hak sudo . Saya mendapatkan kesalahan yang sama persis dengan @ n8henrie tetapi sekarang saya memiliki solusi yang berfungsi dan ingin tahu apakah ini berfungsi untuk orang lain di sini.

Pertama, sedikit latar belakang pengaturan saya:

Saya memiliki skrip cadangan di /Users/myuser/bin bernama restic-backup.sh dengan izin 700 (hanya root/Sudo read/write/execute). Saya menjalankan file ini dengan root crontab saya sudo crontab -e . Saya menggunakan iTerm sebagai terminal default saya. Saya telah menginstal restic dan zsh dengan Homebrew.

macOS versi 10.14.5

restic-backup.sh:

File skrip cadangan saya memiliki yang berikut di dalamnya.

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

Kemudian di file crontab root saya: sudo crontab -e Saya punya:

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

Dalam Akses Disk Penuh:

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

Seperti @n8henrie , saya pikir program yang benar-benar mengakses file seperti restic akan menjadi program yang memerlukan FDA tetapi tampaknya program yang membuat permintaan sudo awal membutuhkan FDA: cron dalam kasus otomatis, dan iTerm.app dalam kasus manual.

Saya menemukan sesuatu yang berguna: ketika memasukkan aplikasi ke daftar putih, itu berlaku untuk skrip atau biner apa pun di dalam direktori aplikasi. Jadi, Anda tidak perlu meluncurkan aplikasi secara langsung. Faktanya, aplikasi itu sendiri sama sekali tidak relevan -- itu hanya bertindak sebagai wadah untuk memasukkan daftar putih. Anda dapat menyalin skrip Anda ke aplikasi arbitrer, memasukkan aplikasi tersebut ke daftar putih, lalu menjalankan skrip Anda. Satu-satunya peringatan adalah Anda harus menghapus dan menambahkan kembali aplikasi ke daftar putih setiap kali Anda mengubah skrip atau biner di dalamnya.

@atticusmatticus @russelldavis -- Saya pikir salah satu pembaruan MacOS baru-baru ini mungkin telah mengubah sesuatu lagi -- Saya pasti telah mencoba kedua strategi itu tanpa hasil. Tetapi saya juga telah mencoba yang di bawah ini, yang telah berhenti berfungsi, tetapi sekarang berfungsi kembali (semacam):

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. Tambahkan biner gotest (dan tidak ada yang lain) ke Akses Disk Penuh
  3. salin daftar ke ~/Library/LaunchAgents/
  4. Muat daemon launchd: launchctl load -w ~/Library/LaunchAgents/com.me.gotest.plist

Sekarang, anehnya, dengan biner gotest , tetapi tidak launchd (atau launchctl ) ditambahkan ke FDA, saya masih tidak dapat menjalankan secara langsung:

$ 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

Tapi itu berjalan tanpa kesalahan dari daemon launchd (setiap 15 detik seperti yang dikonfigurasi), yang tidak berjalan sebagai root ( ~/Library/ bukan /Library/ , dan launchctl load bukan sudo launchctl load ):

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

Anehnya, saya masih melihat, termasuk reboot:

||go binary di FDA|go binary bukan di FDA
---|:---:|:---:
pergi biner tanpa sudo |err|err
pergi biner dengan sudo |err|err
launchd menjalankan go binary|MENJALANKAN|err

Tidak terkait langsung dengan restic, tetapi dengan masalah FDA.
Saya pikir saya punya ide bagaimana itu mungkin bekerja dan saya harap saya tidak menjadi kapten yang jelas. Saya masih gagal menemukan diskusi, artikel, atau dokumentasi yang bermanfaat tentang.

FDA bekerja untuk aplikasi yang masuk daftar putih (membuka berarti mereka diluncurkan oleh launchd), untuk setiap proses turunan dari aplikasi tersebut bahkan yang tidak masuk daftar putih dan untuk binari yang masuk daftar putih jika diluncurkan langsung oleh launchd ( launchd.plist atau launchctl submit ). Ini tidak berfungsi jika biner yang masuk daftar putih diluncurkan di pohon proses dengan aplikasi induk/biner yang tidak masuk daftar putih.

Dari sini sepertinya launchd yang bertanggung jawab untuk pohon proses daftar putih tergantung pada aplikasi/biner yang telah masuk daftar putih.

Dari percobaan sepertinya jalur ke biner harus tepat, jadi daftar putih tidak akan dipicu jika untuk daftar putih launchctl launchctl plist memiliki WorkingDirectory yang ditentukan dan jalur relatif ./some-binary digunakan, itu bahkan tidak akan berfungsi untuk /some/path/./some-binary atau /some/path/../path/some-binary , hanya /some/path/some-binary .
Juga tidak mungkin menggunakan aplikasi yang masuk daftar putih untuk Shebang bahkan jika meluncurkan skrip langsung oleh launchd , jadi #!/some/path/some-binary tidak akan berfungsi, hanya /some/path/some-binary /path/to/script .

Saya pikir kami memiliki informasi dan poin data yang cukup untuk memberikan setidaknya beberapa pedoman (dan mungkin tautan ke masalah ini) di dokumen, dan saya ingin mulai mengerjakannya jika tidak apa-apa.

Haruskah ini menjadi poin baru di bawah Contoh , seperti bagian tentang mencadangkan tanpa menjalankan sebagai root di Linux ?

Saya berencana untuk mencatat bahwa:

  • Akses Disk Penuh diperlukan untuk mencadangkan disk sebanyak mungkin
  • Skrip launchd yang berjalan sebagai root dapat memanggil biner yang masuk daftar putih di bawah FDA tanpa perlu menambahkan launchd ke FDA
  • Kecuali Terminal.app terdaftar di FDA, biner tidak dapat mengakses disk penuh saat dipanggil dari Terminal
  • Jika Terminal.app terdaftar di FDA, itu dapat mengakses disk penuh ketika memanggil biner apakah biner itu ada di FDA atau tidak

Apakah ini terdengar seperti mencerminkan pemahaman dan pengalaman semua orang?

Meskipun agak berbelit-belit, saya senang dengan pengaturan saya yang berjalan di 2 Macbook selama >1 tahun terakhir, dan saya mungkin akan memasukkan bagian-bagiannya sebagai contoh. Pengaturan saya adalah:

  • Saya memiliki skrip shell yang menjalankan perintah restic khusus mesin berdasarkan berbagai variabel lingkungan (skrip yang sama juga berjalan pada 4 komputer Linux, yang memanggil skrip ini secara langsung).
  • Di komputer MacOS saya, saya membangun biner go yang pada dasarnya hanya menjalankan skrip shell di atas. Saya menggunakan skrip shell di sini untuk konfigurasi / pembaruan / kontrol versi yang mudah, meskipun ini juga dapat dengan mudah dilakukan di Go secara langsung.
  • Biner ini ditambahkan ke FDA
  • Saya menjalankan daemon peluncuran seluruh sistem (yang berjalan dengan izin root) untuk meluncurkan biner go ini sesuai jadwal

Menggunakan biner yang mirip dengan https://github.com/restic/restic/issues/2051#issuecomment -442872479 berfungsi untuk saya. Saya menggunakan c karena saya belum menginstalnya sekarang. Bagi orang lain untuk menyalin/menempel:

  1. backup.c
#include <stdlib.h>
int main(void) {
  int status = system("./backup.sh");
  int ret = WEXITSTATUS(status);
  return ret;
}
  1. kompilasi: gcc -Wall -o backup backup.c
  2. daftar putih biner cadangan dan gunakan sesuka Anda

Anehnya, saya masih melihat, termasuk reboot:

jadi biner di FDA jadi biner bukan di FDA
pergi biner tanpa sudo err err
pergi biner dengan sudo err err
launchd running go binary RUNS err

Terima kasih!

Solusi bagi saya adalah membuat file .plist yang memanggil restic secara langsung dan meletakkan semua parameter baik di dalam atau ke dalam file terpisah, menggunakan opsi -p, --exclude-files, --files-from. Dan tentu saja memberikan izin FDA biner restic:

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

Bagaimana menemukan aplikasi mana yang harus ditambahkan ke FDA? Singkatnya, temukan aplikasi yang menjalankannya.

Anda dapat menjaga proses tetap berjalan, dan menjalankan pid induk dari proses hingga pid leluhur adalah 1, diluncurkan melalui ps ajx atau ps ao pid,ppid,command dengan grep .

Dan singkatnya:

  • dijalankan melalui crontab, /usr/sbin/cron , tidak digunakan lagi oleh launchd.plist
  • dijalankan melalui launchd.plist, biner dalam Program atau ProgramArguments
  • jalankan di Terminal, Terminal.app
  • dijalankan melalui ssh, /usr/libexec/sshd-keygen-wrapper atau serupa
  • jalankan melalui aplikasi lain, temukan.

Jadi, untuk @n8henrie , Anda perlu menemukan biner yang sebenarnya.

Cara lain untuk mengatasi ini jika Anda menjalankan sesuatu melalui launchd: LaunchControl sekarang dikirimkan dengan pembantu bernama fdautil yang dapat Anda daftar putih, dan kemudian menjalankan perintah menggunakan fdautil exec . Itu hanya akan mengizinkan perintah yang telah Anda masukkan ke daftar putih melalui LaunchControl atau fdautil set .

Ada sedikit info tentangnya di https://www.soma-zone.com/LaunchControl/FAQ.html , dan detail lebih lanjut di jendela bantuan aplikasi.

Apakah halaman ini membantu?
0 / 5 - 0 peringkat