Sandbox — ano ito, prinsipyo ng paghihiwalay at file system

Ano ang Sandbox

Sandbox — ay isang sistema ng sapilitang kontrol sa pag-access (Mandatory Access Control), na ipinatupad sa antas ng kernel ng iOS (XNU — kernel extension Sandbox.kext). Bawat application sa pagsisimula ay tumatanggap ng natatanging UUID Sandbox profile na tumutukoy kung aling mga system resource ang pinapayagang ma-access.

Ang arkitektura ng Sandbox ay may kasamang tatlong pangunahing bahagi: File System Isolation (bawat application ay nakikita lamang ang sarili nitong container), Network Access Control (mga kahilingan sa lokal na network ay maaaring limitahan) at Inter-Process Communication (pagbabawal sa direktang IPC sa iba pang application). Ipinakilala ng Apple ang Sandbox sa iOS 2.0 at mula noon ay makabuluhang pinahigpit ang mga paghihigpit sa bawat pangunahing bersyon.

Ang Sandbox ay hindi opsyonal — lahat ng application mula sa App Store ay tumatakbo sa sandbox. Hindi maaaring i-disable ng developer ang Sandbox o lampasan ang mga paghihigpit nito. Ang pagtatangkang i-access ang ipinagbabawal na resource ay nagtatapos sa error na may code na EPERM (Operation not permitted) at pagtatala sa system log.

import Foundation

// Pagtatangkang i-access ang file ng ibang application — nagbabalik ng nil
let otherAppPath = "/var/mobile/Containers/Data/Application/OTHER-UUID/Documents/file.txt"
let data = try? Data(contentsOf: URL(fileURLWithPath: otherAppPath))
// data == nil — Hina-block ng Sandbox ang access

// Tamang access — sa loob ng sariling Sandbox
let fileManager = FileManager.default
guard let documentsURL = fileManager.urls(
    for: .documentDirectory,
    in: .userDomainMask
).first else { return }

let myFileURL = documentsURL.appendingPathComponent("notes.txt")
try "Hello, Sandbox!".write(to: myFileURL, atomically: true, encoding: .utf8)

Istraktura ng sandbox ng application

Ang Sandbox ng bawat application sa iOS ay naglalaman ng ilang paunang natukoy na direktoryo, naa-access sa pamamagitan ng Foundation API. Ang lokasyon sa physical media — /var/mobile/Containers/Data/Application/{UUID}/, ngunit ang mga developer ay hindi dapat gumamit ng path na ito nang direkta: ito ay nagbabago sa bawat pag-restart ng device sa iba't ibang bersyon ng iOS.

Mga pangunahing direktoryo ng Sandbox: Bundle (.app — read-only, naglalaman ng executable code at resources), Documents (data ng user, naba-backup sa iCloud), Library (Caches, Preferences, Application Support — na may iba't ibang panuntunan sa pag-backup), tmp (mga pansamantalang file, tinatanggal ng system kapag walang sapat na espasyo). Bawat direktoryo ay may sariling lifecycle at patakaran sa pag-iimbak.

Ang pisikal na path sa Sandbox ay maaaring makuha sa pamamagitan ng NSHomeDirectory() o FileManager.url(for: .documentDirectory). Inirerekomenda ng Apple ang paggamit ng URL-based API dahil ina-abstract nito ang panloob na istraktura ng file system at nananatiling stable sa mga pagbabago sa macOS Sandbox sa desktop.

Pag-access sa mga file sa labas ng sandbox

Direktang pag-access sa file system ng iba pang application sa iOS ay ganap na naka-block. Kahit na alam ng developer ang UUID ng container ng ibang application, ang Sandbox sa antas ng kernel ay magbabalik ng error sa pagtatangkang magbasa o magsulat. Ito ang pangunahing pagkakaiba sa pagitan ng iOS at macOS, kung saan ang Sandbox ay mas flexible.

Ang Apple ay nagbibigay ng tatlong lehitimong mekanismo para sa pagpapalitan ng data sa pagitan ng mga application: UIDocumentPickerViewController (pinipili ng user ang file sa pamamagitan ng system interface, ang application ay tumatanggap ng Security-Scoped URL), Share Extension (extension para sa paglipat ng data sa ibang application) at App Groups (shared directory para sa mga application ng parehong developer).

UIDocumentPicker — tanging paraan upang makakuha ng access sa mga file mula sa iba pang application nang walang paunang configuration. Tahasang pinipili ng user ang file sa pamamagitan ng standard system picker, at ang iOS ay nagbibigay sa application ng pansamantalang Security-Scoped URL. Ang access ay may bisa hanggang sa pagsasara ng picker o hanggang sa pagtawag ng stopAccessingSecurityScopedResource.

Security-Scoped Bookmarks

Security-Scoped Bookmark — ay isang mekanismo ng iOS na nagbibigay-daan upang mapanatili ang access sa isang file sa labas ng Sandbox sa pagitan ng mga paglulunsad ng application. Kapag pinili ng user ang isang file sa pamamagitan ng UIDocumentPicker, ang application ay maaaring lumikha ng bookmark mula sa Security-Scoped URL at i-save ito sa UserDefaults o iba pang storage.

Sa susunod na paglulunsad, ang application ay nagre-restore ng access sa pamamagitan ng URLByResolvingBookmarkData, na nagbabalik ng Security-Scoped URL. Pagkatapos ay kailangang tawagan ang startAccessingSecurityScopedResource bago basahin ang file at stopAccessingSecurityScopedResource pagkatapos ng trabaho. Balanse ng mga tawag ay sapilitan — bawat start ay dapat may katumbas na stop, kung hindi ay mauubos ng system ang limitasyon ng Security-Scoped resources.

// Gumawa ng Security-Scoped Bookmark
func createBookmark(for url: URL) -> Data? {
    return try? url.bookmarkData(
        options: .minimalBookmark,
        includingResourceValuesForKeys: nil,
        relativeTo: nil
    )
}

// I-resolve ang bookmark data sa URL
func resolveBookmark(data: Data) -> URL? {
    var isStale = false
    let url = try? URL.byResolvingBookmarkData(
        data,
        options: .withoutUI,
        relativeTo: nil,
        bookmarkDataIsStale: &isStale
    )
    
    if isStale {
        // Luma na ang bookmark, kailangan gumawa ng bago
    }
    
    return url
}

Mahalagang limitasyon: Ang Security-Scoped Bookmarks ay hindi gumagana para sa mga file sa loob ng sariling Sandbox — para lamang sa mga file na nakuha sa pamamagitan ng UIDocumentPicker o iCloud Drive. Ang bookmark ay naglalaman ng Security-Scoped data na nagbibigay-daan sa system na tukuyin kung aling application at para sa aling file ang humihiling ng access. Kung ang certificate ng application ay mag-expire o magbago, ang bookmark ay magiging invalid.

Sandbox at App Groups

App Groups — mekanismo ng iOS na nagpapahintulot sa maraming application (at kanilang mga extension) mula sa parehong developer na magkaroon ng shared Sandbox directory. Para i-enable, kailangang idagdag ang Capability App Groups sa Xcode at tukuyin ang parehong group identifier para sa lahat ng target na application.

Ang shared App Groups directory ay nasa labas ng Sandbox ng bawat indibidwal na application, ngunit lahat ng application sa grupo ay may buong access dito para sa pagbasa at pagsulat. Ito ay nagbibigay-daan sa pagpapalitan ng mga file, database (Core Data na may Store URL sa App Group) at UserDefaults (sa pamamagitan ng initWithSuiteName) sa pagitan ng pangunahing application, Today Widget, Watch Extension at Share Extension.

Inirerekomenda ng Apple ang paggamit ng App Groups para sa pag-sync ng estado sa pagitan ng application at ng mga extension nito. Halimbawa, ang Today Widget ay maaaring magbasa ng data mula sa shared App Group directory kung saan ang pangunahing application ay nagsusulat ng kasalukuyang data. Gayunpaman, bawat application ay nananatiling nakahiwalay mula sa iba pang App Groups — tanging ang mga application na may parehong group identifier ang may access.

Mga limitasyon ng sandbox sa iOS

Ang Sandbox sa iOS ay nagpapataw ng ilang mahigpit na limitasyon na dapat isaalang-alang sa pag-develop. Ang mga pangunahing: pagbabawal sa dynamic na code (pag-load at pag-execute ng code sa labas ng Sandbox), pagbabawal sa direktang pag-access sa address book, kalendaryo at mga larawan nang walang pahintulot ng user (Privacy framework), at mga limitasyon sa paglikha ng child process (fork, exec ay ipinagbabawal).

Network: ang mga application ay maaaring kumonekta sa anumang remote server sa pamamagitan ng TCP/UDP, ngunit ang access sa localhost ay limitado — ang iba pang application ay hindi maaaring kumonekta sa server sa loob ng iyong application (maliban sa debug builds). Multicast at broadcast UDP ay naka-block din para sa App Store application.

Hardware resources: ang access sa camera, mikropono, geolocation, Bluetooth at HealthKit ay nangangailangan ng tahasang pahintulot ng user sa pamamagitan ng system dialog. Para sa bawat uri ng resource, ang iOS ay gumagamit ng hiwalay na entitlement at Info.plist key na may paglalarawan ng dahilan (NSPhotoLibraryUsageDescription, NSCameraUsageDescription). Ang paghingi ng pahintulot nang walang paglalarawan ng dahilan sa Info.plist ay nagreresulta sa pagtatapos ng application.

• Dynamic na code — ipinagbabawal: JavaScriptCore para sa JS sa WebView, ngunit hindi arbitrary machine code
• Child process — fork, exec, system hindi available mula sa Sandbox
• Access sa mga device — camera, mikropono, GPS ay nangangailangan ng system dialog
• Lokal na network — multicast at broadcast UDP naka-block para sa App Store
• Encryption key — Keychain available, ngunit para lamang sa sariling application (kSecAttrAccessGroup para sa App Group)