Deaktivieren Sie die Kennwortanforderung für den Bildschirmschoner über die Befehlszeile

Ich versuche, die Kennwortanforderung für den Bildschirmschoner über die Befehlszeile zu aktivieren und zu deaktivieren.

defaults read com.apple.screensaver

zeigt eine Variable askForPassword, die entweder auf 0 oder 1 gesetzt ist, je nachdem, ob ich eine Passwortanforderung in den Systemeinstellungen konfiguriert habe oder nicht.

defaults write com.apple.screensaver askForPassword 1

und

defaults write com.apple.screensaver askForPassword 0

Aktivieren und deaktivieren Sie die Passworteinstellung, oder so dachte ich.

Was ich stattdessen finde, ist, dass die Befehle zwar das Kontrollkästchen in den Systemeinstellungen unter Sicherheit aktivieren und deaktivieren, sich aber überhaupt nicht auf den Bildschirmschoner auswirken.

Wenn ich das Passwort in den Systemeinstellungen aktiviere und es dann mit dem zweiten Standardschreibbefehl deaktiviere, ist das Kontrollkästchen in den Systemeinstellungen deaktiviert, aber der Bildschirmschoner fragt weiterhin nach einem Passwort. Nur das Aktivieren und Deaktivieren des Kontrollkästchens in den Systemeinstellungen kann dieses Verhalten jetzt ändern.

Und wenn ich das Passwort in den Systemeinstellungen deaktiviere und es dann mit dem ersten Standardschreibbefehl aktiviere, ist das Kontrollkästchen in den Systemeinstellungen aktiviert, aber der Bildschirmschoner fragt nicht nach einem Passwort. Nur das Deaktivieren und Aktivieren des Kontrollkästchens in den Systemeinstellungen ändert das Verhalten danach.

Was ist los?

Ich kann mir vorstellen, dass dies eine globale Einstellung ist und ich /Library/Preferences/com.apple.screensaveranstelle der Benutzerdomäne ändern sollte. Aber warum gibt es in diesem Fall eine Auswirkung auf das Kontrollkästchen Systemeinstellungen?

Das ist ein wenig verwirrend. Ich habe das Lesen/Schreiben von Dateien beobachtet, während ich die Einstellung „Nach dem Passwort fragen“ umgeschaltet habe. Die einzige Datei, die ich sehen kann, ist com.apple.screensaver. Ich vermute, dass eine Nachricht an einen Dienst gesendet wird, wenn diese Schaltfläche in der GUI umgeschaltet wird und in die Plist-Datei geschrieben wird. Ich würde wetten, dass ein Neustart des Systems oder ein Ab-/Anmelden dazu führen könnte, dass die Datei von diesem Dienst erneut gelesen wird und die gewünschte Änderung vornimmt.
Ich lag richtig! Wenn Sie sich nach dem Ändern der Plist-Datei abmelden und wieder anmelden, wird die Änderung der Einstellungen übernommen. Es sieht also so aus, als müssten Sie herausfinden, welcher Dienst das Verhalten „Nach dem Passwort fragen“ steuert, und es zurücksetzen/neu laden, nachdem Sie die plist geändert haben.
Sieht so aus, als würde Apple seinen eigenen Plist-Mechanismus untergraben.
Ta. Ich hoffe jemand weiß das und antwortet hier.
Es ist der 'loginwindow'-Prozess, der auf diese Datei zuzugreifen scheint, nachdem sie von den Systemeinstellungen geschrieben wurde. Was Sinn macht. Leider werden Sie durch das Beenden des Anmeldefenster-Prozesses zwangsweise abgemeldet. Graben Sie weiter!
@macaco Können Sie bitte die Methode beschreiben, die Sie zum Überwachen des Lesens/Schreibens von Dateien verwendet haben, bei der die Einstellung „Passwort abfragen“ umgeschaltet wurde?

Antworten (2)

Wenn Sie nicht gezwungen sind, Standardwerte zu verwenden , können Sie den folgenden Befehl verwenden. Es interagiert mit dem Betriebssystem genauso, als ob Sie die Systemeinstellungen verwenden würden.

GETESTET AUF:

  • 10.5.x
  • 10.6.x
  • 10.7.x
  • 10.8.x
  • 10.9.x

sudo osascript -e 'tell application "System Events" to set require password to wake of security preferences to false'

HINWEIS: Wenn der Befehl innerhalb eines Skripts ausgeführt wird, das Root-Rechte erhalten hat, benötigen Sie das sudo nicht .

osascript -e 'tell application "System Events" to set require password to wake of security preferences to false'
Nett! Die Befehlszeile AppleScript ist oft eine gute Lösung für diese Art von Problem.
@DanielLawson Danke, arbeitest du gerade an 10.7? Im Allgemeinen poste ich gerne, auf welchen Betriebssystemen ich meine Befehle getestet habe, und leider stecke ich heute Morgen mit einem alten Snow Leopard-Computer fest und habe bis später heute keinen Zugriff auf einen 10.7-Computer. Ich würde es hassen, wenn es unter 10.6.x funktioniert und unter 10.7 fehlschlägt :–( Ich bin mir jedoch ziemlich sicher, dass dies funktionieren wird, da die plists sehr ähnlich sind. Ich weiß, dass die screensaver.plist von 10.5 anders ist und einige Anpassungen erforderlich wären . Trotzdem danke nochmal. :–)
Ich habe Arbeitsmaschinen mit 10.7, 10.5 und 10.3, bin aber im Moment von allen fern. Ich würde es mir in diesem Zusammenhang gerne anschauen, kann aber erst heute Abend oder morgen.
@DanielLawson Ich habe meine Antwort bearbeitet, um die Tests von 10.5.x 10.6.x 10.7.3 widerzuspiegeln. Der Befehl funktionierte für jedes Betriebssystem. Danke noch einmal.
Ich habe dies auf 10.7.5 auf OS X Server getestet und es funktioniert nicht. Der Bildschirmschoner erfordert weiterhin ein Passwort und die Einstellung ist nicht deaktiviert.
Das funktioniert bei mir am 10.11 (El Capitan). Habe es in diesem Thread gefunden ( github.com/dustinrue/ControlPlane/issues/421 )
Die "osascript"-Methode funktioniert auf meinem High Sierra Mac nicht. Die Datei ~/Library/Preferences/com.apple.screensaver.plist scheint nicht vom GUI-Schalter auf meinem High Sierra Mac betroffen zu sein.

Ich bin auf ein ähnliches Problem gestoßen und habe in diesem Forumsbeitrag eine Lösung von Benutzer Guillaume gefunden . Grundsätzlich müssen Sie den Bildschirmschoner zwingen, die Einstellung für die Kennwortanforderung erneut zu lesen, was Sie mit einem C-Programm tun können:

#include <CoreFoundation/CoreFoundation.h>

int main(int argc, char ** argv)
{
    CFMessagePortRef port = CFMessagePortCreateRemote(NULL, CFSTR("com.apple.loginwindow.notify"));
    CFMessagePortSendRequest(port, 500, 0, 0, 0, 0, 0);
    CFRelease(port);
    return 0;
}

Und kompilieren Sie dies mit:

cc -o /tmp/anywhereyouwantit/notif notif.c -framework CoreFoundation

Dann rufen Sie dieses Programm sofort nach Ihrem Aufruf aufdefaults write

Update: Auf High Sierra (10.13.6) wird dies kompiliert, meldet aber diesen Fehler: „ld: warning: text-based stub file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation.tbd and library file /System/Library /Frameworks//CoreFoundation.framework/CoreFoundation sind nicht synchron. Zum Verknüpfen wird auf die Bibliotheksdatei zurückgegriffen." Es schlägt bei der Ausführung mit einem Segmentierungsfehler fehl.
@TJLuoma das liegt daran, dass Ihre Build-Umgebung nicht richtig konfiguriert ist. llvm meldet diesen Fehler für jede Datei, die Sie mit Frameworks kompilieren. Der Segmentierungsfehler ist jedoch auf ein anderes Problem zurückzuführen. Sieht so aus, als würde CFMessagePortCreateRemote eine Null für den Port zurückgeben. Daher SendRequest-Fehler. Ich vermute, dass der Name des Remote-Nachrichtenports ungültig ist, aber ich weiß nicht, wie er lauten sollte.