Swift: iOS Data Protection wenn Device geschützt (Couchbase, CouchDB)

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Swift: iOS Data Protection wenn Device geschützt (Couchbase, CouchDB)

    Hi,

    auf der Suche nach Hilfe für mein Problem, bin ich auf dieses Forum gestoßen.
    Ich hoffe hier kann mir geholfen werden :)

    Ich bin derzeit damit beschäftigt eine App zu programmieren die mit couchbaselite arbeitet und im Background (via Background Fetch) eine Replikation zwischen Couchbaselite des Gerätes und einer CouchDB durchführen soll.
    Das Ganze funktioniert auch schon, außer man startet den Background Fetch wenn das iPhone gelockt ist. Die folgenden Fehlermeldungen erscheinen:

    Quellcode

    1. Failed to Load DB 'DBNAME': Error Domain=SQLite Code=23 "authorization denied" UserInfo={NSLocalizedDescription=authorization denied}
    2. error opening!: 23


    Den CBLManager starte ich zu Beginn wie folgt:

    Quellcode

    1. var error:NSError?
    2. let options:CBLManagerOptions = CBLManagerOptions(readOnly: false, fileProtection: NSDataWritingOptions.DataWritingFileProtectionCompleteUntilFirstUserAuthentication)
    3. let poptions:UnsafePointer<CBLManagerOptions> = UnsafePointer<CBLManagerOptions>.init(UnsafeMutablePointer<CBLManagerOptions>.alloc(1).initialize(options))
    4. manager = CBLManager(directory: CBLManager.defaultDirectory(), options: poptions, error: &error)

    Hat jemand von euch Erfahrung damit oder kann mir spontan irgendwie helfen?

    Vielen Dank im Voraus!
  • Danke für deine Antwort :)
    Ich kann aber sicher sagen, dass es funktioniert.
    Die Tests beweisen ja auch die Funktionalität im nicht gelockten Zustand des iPhones.

    Ich weiß nicht, ob ich das oben schon beschrieben hatte, aber es scheint wirklich so zu sein, dass ios den Zugriff auf die DB sperrt, wenn das iphone gesperrt ist.
    Ich hatte die Hoffnung, dass jemand von euch eventuell genau dasselbe Problem bereits hatte.
  • Daran hab ich auch schon gedacht, deshalb hab ich den CBLManager auch mit den Attributen ausgestattet, die das eigentlich verhindern "sollten" :D

    Quellcode

    1. let options:CBLManagerOptions = CBLManagerOptions(readOnly: false, fileProtection: NSDataWritingOptions.DataWritingFileProtectionCompleteUntilFirstUserAuthentication)
    Eigentlich sollte ich diesem Problem damit doch aus dem Weg gehen? Sofern ich das richtig implementiert habe.
    Data Protection ist im Projekt nicht aktiviert, also greift eigentlich nur die "normale" Encryption der Dateien, bei gelocktem Device.

    Könnte ich diese FileProtection auch auf ganze Ordner anwenden?
    Die ganzen Datenbanken liegen nämlich unter "Application Support/CouchbaseLite/".

    Vielen Dank im Voraus


    edit:
    "By setting up a device passcode, the user automatically enables Data Protection."
    Sehr interessantes Paper, werde ich mich wohl mit auseinander setzen müssen ... Aber es muss doch auch möglich sein, im gelockten Zustand (mit Passcode) an der DB arbeiten zu können?

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Lukas308 ()

  • Ich bin noch komplett neu in der ios Programmierung und diese App hier ist der erste Versuch mit der Sprache Swift, deshalb die Frage:

    Stimmt dieser Code so?

    Quellcode

    1. var error:NSError?
    2. let options:CBLManagerOptions = CBLManagerOptions(readOnly: false, fileProtection: NSDataWritingOptions.DataWritingFileProtectionCompleteUntilFirstUserAuthentication)
    3. let poptions:UnsafePointer<CBLManagerOptions> = UnsafePointer<CBLManagerOptions>.init(UnsafeMutablePointer<CBLManagerOptions>.alloc(1).initialize(options))
    4. manager = CBLManager(directory: CBLManager.defaultDirectory(), options: poptions, error: &error)

    Ich hatte etwas Probleme mit dem UnsafePointer und das hier ist nach einigem Probieren entstanden.
    Ich glaube hier könnte der Fehler liegen, weil er durch diese Code-Zeilen eigentlich dafür sorgen sollte, dass die FileProtection auf None gesetzt wird, aber wenn ich das für meine DBs abfrage steht es standardmäßig auf NSFileProtectionCompleteUnlessOpen.
  • Lukas308 schrieb:

    Kann ich für die gesamte App die Data Protection ausschalten?
    Meinst du damit etwa den Menüpunkt im Projekt? Wenn ja, dann ist das deaktiviert.
    Das ging früher™ mal. Aber ich bin da nicht mehr auf dem Laufenden. Seit der vor-/letzten Systemversion ist das wohl per default systemweit für alle Apps aktiviert.

    Aber nach meinem Wissen (evtl. nicht mehr aktuell) benötigt File Protection zwingend die Codesperre. Was Du demzufolge mal (ohne Gewähr) versuchen kannst:
    Lösche die App vom Gerät. Gehe in die Einstellungen > Code. Unten in der letzten Zeile steht etwas wie "Schutz der Daten aktiv". Jetzt schaltest Du die Codeeingabe ab. Dann sollte diese Zeile weg sein. Wenn ja, dann müsste Data Protection jetzt inaktiv sein, so daß neuinstallierte Apps dies nicht mehr benutzen können. App wieder installieren und wie gehabt testen.


    P.S.:

    Lukas308 schrieb:

    Ich glaube hier könnte der Fehler liegen, weil er durch diese Code-Zeilen eigentlich dafür sorgen sollte, dass die FileProtection auf None gesetzt wird, aber wenn ich das für meine DBs abfrage steht es standardmäßig auf NSFileProtectionCompleteUnlessOpen.
    Ja, NSFileProtectionCompleteUnlessOpen sieht (wie eingangs vermutet) sehr nach der Ursache deines Problems aus. (Zitat: "A closed file is inaccessible while the device is locked.") - Aber zu SWIFT kann ich leider gar nichts sagen.
    * Kann Spuren von Erdnüssen enthalten.

    Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von NSObject ()

  • Als Lösung für alle, die vielleicht auch mal irgendwann an diesem Problem hängen sollten :D


    Quellcode

    1. var error: NSError?
    2. let cbloptions = CBLManagerOptions(readOnly: false, fileProtection: NSDataWritingOptions.DataWritingFileProtectionNone)
    3. let cblpoptions=UnsafeMutablePointer<CBLManagerOptions>.alloc(1)
    4. cblpoptions.initialize(cbloptions)
    5. manager = CBLManager(directory: CBLManager.defaultDirectory(), options: cblpoptions, error: &error)

    Es lag wirklich daran wie wir den CBLManager initialisiert haben. Mit den oben genannten Code-Zeilen läuft es jetzt.
    Vielen Dank für eure Unterstützung =)
  • Wird man als User eigentlich informiert wenn eine App auch Verbindungen aufbaut während diese gar nicht läuft? Mir gruselt es gerade gewaltig ob der ganzen neuen Swift Programmierer hier die alle fragen wie man im Hintergrund auch bei gelocktem iPhone noch Daten empfangen und verschicken kann.... Bald haben wir auf dem iPhone dann Android Verhältnisse.

    Warum hat Apple das nur zugelassen?
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Was hat das mit Swift zu tun?

    In gewisser Weise teile ich Deine Bedenken allerdings. Ich sehe darin jedoch eher ein allgemeines gesellschaftliches Problem. Ich finde es teilweise erschreckend, wie unbedarft einige Leute mit Themen wie Vertraulichkeit, Datenschutz, Sicherheit, etc. umgehen, besonders hier, in einem Datenumfeld, wo ich diesbezüglich mehr Sensibilität erwarten würde.

    Letztens gerade sinngemäß im Forum:
    Q: "Ich kann keine verschlüsselte Verbindung aufbauen. Hilfe!"
    A: "Schick's doch einfach per http."

    *ditsch*

    Und dann all die User, die sich komplett mit der selbstherrlichen, autokratischen App-Vertriebsstruktur abgefunden haben... Da muß man dann bei Apple höflichst anfragen, ob und wie man auf einem anderen Device was installieren darf, und alle akzeptieren das anscheinend schulterzuckend.

    Das ganze hat nichts mit Swift, der Programmiersprache zu tun.

    PS: Sorry für den rant. Mußte bei der Gelegenheit mal raus. ;)
  • @Thallius:
    Das ist ja kein Problem das Swift verursacht.

    @tsunamix:
    Wenn er sich nicht an die deutschen Datenschutzgesetze hält oder es mit der Datensicherheit nicht so genau nimmt, kannst Du ihn bei der zuständigen Datenschutzaufsicht melden. Und die sind da - im Gegensatz zu früher - wenig zimperlich. Unwissenheit ist heute keine Ausrede mehr.
    * Kann Spuren von Erdnüssen enthalten.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von NSObject ()

  • Hi,

    gerade gelesen, dass mein Thread noch diskutiert wird.
    Ich kann die Bedenken verstehen und ja eigentlich ist das nicht Sinn der Sache, den Schutz den iOS bietet einfach zu umgehen.

    Zu meiner Verteidigung kann ich aber sagen, dass es bei unserer Entwicklung um ein Projekt fürs Studium geht, es die App als solches schon für Android gibt und unser Auftrag lautete es bestenfalls 1:1 in iOS zu portieren. Die App wird wohl auch nie den Weg in den App Store finden, von daher ist es in diesem Beispiel wirklich irrelevant sich über Sicherheitslücken den Kopf zu zerbrechen.

    @Thallius weißt du was Apps wie Facebook, Twitter und co. im Hintergrund treiben? Ich nicht und ich will es besser auch nicht wissen ...
  • Lukas308 schrieb:

    Hi,

    gerade gelesen, dass mein Thread noch diskutiert wird.
    Ich kann die Bedenken verstehen und ja eigentlich ist das nicht Sinn der Sache, den Schutz den iOS bietet einfach zu umgehen.

    Zu meiner Verteidigung kann ich aber sagen, dass es bei unserer Entwicklung um ein Projekt fürs Studium geht, es die App als solches schon für Android gibt und unser Auftrag lautete es bestenfalls 1:1 in iOS zu portieren. Die App wird wohl auch nie den Weg in den App Store finden, von daher ist es in diesem Beispiel wirklich irrelevant sich über Sicherheitslücken den Kopf zu zerbrechen.

    @Thallius weißt du was Apps wie Facebook, Twitter und co. im Hintergrund treiben? Ich nicht und ich will es besser auch nicht wissen ...

    Deshalb kommen diese Apps auch nicht auf mein Handy. Da gehe ich lieber den umbequemeren Weg über den Browser.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Deine Einstellung ist richtig.
    Leider hat sich diese Egal Einstellung aber weitverbreitet. Ich glaube, wenn man nicht selbst mit der Thematik etwas in Berührung kommt, sei es durch den Job, Studium oder einfaches Interesse daran, wäre unsere Meinung zum Thema Datenschutz auch nicht dieselbe.

    Also ihr könnt mir glauben, was Datenschutz angeht bin ich der selben Meinung wie ihr ;)

    Deshalb wollte ich oben auch nochmal erklären wieso ich die Protection umgehe. Im Normalfall würde ich eine App von vornherein schon anders planen damit ich in diese Situation niemals kommen würde.