El usuario root (UID 0) existe en cada sistema operativo Unix o similar a Unix. Todos los procesos de un sistema operativo Unix deben ejecutarse como un usuario / UID válido, independientemente de los procesos del sistema, demonios, servicios o aplicaciones iniciadas por el usuario. Cada proceso básico del sistema se ejecuta bajo UID 0 (raíz), y cada archivo relevante para el sistema es propiedad de ese usuario. Por razones de seguridad, algunos procesos se ejecutan como "usuarios" diferentes con menos privilegios que el root del superusuario. Dichos usuarios están allí con el único propósito de iniciar servicios, como un servidor web, una base de datos, el servidor de ventanas, etc. Esto significa que no todos los usuarios configurados en Unix (o macOS) son usuarios "reales". De hecho, la mayoría de los usuarios del sistema no pueden iniciar sesión de forma interactiva.
Por ejemplo, un script que se ejecuta bajo UID 0 (= root ) iniciará un servidor web (nginx, apache, ...). El proceso del servidor web luego elimina los privilegios a un UID específico (en este caso, podría ser el usuario www ). www no es un usuario real y no se puede utilizar para iniciar sesión en el sistema de forma interactiva.
Hay dos formas de "desactivar" un usuario (del sistema):
- configura el shell del usuario en / bin / false (o cualquier shell no válido)
- inhabilite la contraseña del usuario, configurándola en un valor no válido, vacío o específico.
En macOS AFAIK, un usuario no válido tiene una contraseña vacía y una propiedad específica establecida en el servidor local de OpenDirectory.
Por lo general, para una solicitud como "es este un usuario válido", el servicio OpenDirectory en macOS realiza una comprobación simple del usuario solicitado y devuelve verdadero (el usuario puede iniciar sesión) o falso (el usuario no puede iniciar sesión).
Parece que el error de Apple no fue para verificar la validez del usuario, sino para establecer como habilitado. En las cuentas ya habilitadas, esto no tuvo efecto, pero las cuentas deshabilitadas se volvieron válidas, las cuentas habilitadas. Y como un usuario deshabilitado no tiene contraseña, se aceptó una contraseña vacía como una opción válida para iniciar sesión como superusuario / root .