Deshabilitar el requisito de contraseña del protector de pantalla desde la línea de comandos

Estoy tratando de habilitar y deshabilitar el requisito de contraseña del protector de pantalla desde la línea de comando.

defaults read com.apple.screensaver

muestra una variable askForPassword establecida en 0 o 1, dependiendo de si configuré un requisito de contraseña en Preferencias del sistema o no.

defaults write com.apple.screensaver askForPassword 1

y

defaults write com.apple.screensaver askForPassword 0

habilitar y deshabilitar la configuración de contraseña, o eso pensé.

En cambio, lo que encuentro es que los comandos marcan y desmarcan la casilla de verificación en Preferencias del sistema en Seguridad, pero no afectan en absoluto al protector de pantalla.

Si habilito la contraseña en las Preferencias del Sistema y luego la deshabilito usando el segundo comando de escritura predeterminado, la casilla de verificación en las Preferencias del Sistema no está marcada, pero el protector de pantalla seguirá solicitando una contraseña. Solo marcar y desmarcar la casilla de verificación en Preferencias del sistema puede cambiar este comportamiento ahora.

Y si deshabilito la contraseña en Preferencias del sistema y luego la habilito usando el primer comando de escritura predeterminado, la casilla de verificación en Preferencias del sistema está marcada, pero el protector de pantalla no solicitará una contraseña. Solo desmarcando y marcando la casilla de verificación en Preferencias del sistema cambia el comportamiento después.

¿Que esta pasando?

Puedo imaginar que esta es una configuración global y debería modificar /Library/Preferences/com.apple.screensaveren lugar del dominio del usuario. Pero en ese caso, ¿por qué hay un efecto en la casilla de verificación Preferencias del Sistema?

Esto es un poco desconcertante. He visto la lectura/escritura de archivos mientras alternaba la configuración de 'pedir contraseña'. El único archivo que puedo ver modificado es com.apple.screensaver. Supongo que se envía un mensaje a algún servicio cuando este botón se activa en la GUI y se escribe en el archivo plist. Apuesto a que reiniciar el sistema o cerrar sesión/iniciar sesión podría hacer que dicho servicio vuelva a leer el archivo, realizando el cambio deseado.
¡Yo tenía razón! Cerrar sesión y luego volver a iniciarla después de cambiar el archivo plist hace que se refleje el cambio en la configuración. Entonces, parece que necesita encontrar qué servicio está controlando el comportamiento de 'solicitar contraseña' y restablecerlo/recargarlo después de modificar el plist.
Parece que Apple socava su propio mecanismo de plist.
Ejército de reserva. Espero que alguien sepa eso y responda aquí.
Es el proceso de 'ventana de inicio de sesión' el que parece acceder a este archivo después de que haya sido escrito por Preferencias del sistema. Lo cual tiene sentido. Desafortunadamente, matar el proceso de la ventana de inicio de sesión lo cerrará por la fuerza. ¡Sigue cavando!
@macaco ¿Puede describir el método que usó para monitorear la lectura/escritura de archivos que alternó la configuración de 'solicitar contraseña'?

Respuestas (2)

Si no está obligado a usar la escritura predeterminada , puede usar el siguiente comando. Interactúa con el sistema operativo de la misma manera que si fuera a utilizar las preferencias del sistema.

PROBADO EN:

  • 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'

NOTA: Si el comando se ejecuta dentro de un script al que se le han otorgado privilegios de root, no necesitará el sudo .

osascript -e 'tell application "System Events" to set require password to wake of security preferences to false'
¡Bonito! La línea de comandos AppleScript suele ser una buena solución para este tipo de problema.
@DanielLawson Gracias, ¿está trabajando actualmente en 10.7? Por lo general, me gusta publicar los sistemas operativos en los que he probado mis comandos y, lamentablemente, esta mañana estoy atascado con una vieja máquina Snow Leopard y no tendré acceso a una máquina 10.7 hasta más tarde hoy. Odiaría que funcionara en 10.6.x y fallara en 10.7 :–( Sin embargo, estoy bastante seguro de que funcionará ya que las plists son muy similares. Sé que screensaver.plist de 10.5 es diferente y se necesitarán algunos ajustes De todos modos, gracias de nuevo. :–)
Tengo máquinas en funcionamiento que ejecutan 10.7, 10.5 y 10.3, pero estoy lejos de todas ellas en este momento. Me encantaría echarle un vistazo en ese contexto, pero no puedo hasta esta noche o mañana.
@DanielLawson Edité mi respuesta para reflejar la prueba de 10.5.x 10.6.x 10.7.3. El comando funcionó para cada sistema operativo. Gracias de nuevo.
He probado esto en 10.7.5 en OS X Server y no funciona. El protector de pantalla aún requiere una contraseña y la preferencia no está desmarcada.
Esto me funciona el 10.11 (El Capitán). Lo encontré en este hilo ( github.com/dustinrue/ControlPlane/issues/421 )
El método "osascript" no funciona en mi High Sierra Mac. El archivo ~/Library/Preferences/com.apple.screensaver.plist no parece verse afectado por el cambio de GUI en mi High Sierra Mac.

Me encontré con un problema similar y encontré una solución del usuario Guillaume en esta publicación del foro . Básicamente, debe forzar el protector de pantalla para que vuelva a leer la preferencia de requisito de contraseña, lo que puede hacer con un programa C:

#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;
}

Y compila esto con:

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

Entonces llame a este programa inmediatamente después de su llamada adefaults write

Actualización: en High Sierra (10.13.6) esto compila, pero informa este error: "ld: advertencia: archivo auxiliar basado en texto /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation.tbd y archivo de biblioteca /System/Library /Frameworks//CoreFoundation.framework/CoreFoundation no están sincronizados. Volviendo al archivo de biblioteca para vincular". Falla con una falla de segmentación cuando se ejecuta.
@TJLuoma eso se debe a que su entorno de compilación no está configurado correctamente. llvm informará ese error para cada archivo que compile utilizando marcos. Sin embargo, la falla de segmentación se debe a un problema diferente. Parece que CFMessagePortCreateRemote devuelve un valor nulo para el puerto. Por lo tanto, las fallas de SendRequest. Supongo que el nombre del puerto de mensajes remoto no es válido, pero no sé cuál debería ser.