Caso: revisa los permisos de un archivo Linux

Harbor Archive, un proyecto ficticio, genera resúmenes internos mediante un servicio de exportación. Nina aprueba el acceso a los datos; Leo mantiene el servicio. Piden una revisión escrita antes de cualquier cambio. Tu entregable es una propuesta razonada, no instrucciones para operar una máquina.

Una revisión de permisos compara autoridad efectiva sobre un recurso con su necesidad aprobada y registra diferencias, evidencias y cuestiones pendientes.

Etapa 1: establece las reglas del caso

Supón procesos ordinarios sin privilegios especiales, ACL de acceso Linux válidas y las identidades y pertenencias indicadas. Los directorios padre permiten recorrer la ruta. No hay capacidades que omitan controles, políticas adicionales de bloqueo ni descriptores de archivo previamente abiertos que alteren estas decisiones. Evalúa solicitudes nuevas de lectura o escritura del contenido de archivos regulares. Eliminar o reemplazar entradas de directorio queda fuera del expediente.

E1: requisitos aprobados por Nina. La identidad archive-worker necesita leer y escribir resúmenes. Los miembros de reviewers pueden leerlos, pero no cambiar su contenido. Maya, ajena a reviewers y TempCrew, puede leer solo legacy-summary hasta el viernes. TempCrew y otras identidades no tienen acceso al contenido aprobado. La excepción temporal de Maya no abarca resúmenes futuros.

E2: ACL de acceso completa de legacy-summary. Su propietario es archive-worker y su grupo propietario, reviewers. Las identidades usadas para evaluar TempCrew y other no son el propietario ni pertenecen a reviewers.

E3: política propuesta para archivos nuevos. El servicio solicita modo 0666 con máscara de creación 0027 en un directorio sin ACL predeterminada. Los archivos nuevos pertenecen a archive-worker y reviewers. Una muestra suministrada se creó directamente allí como 0640, sin entradas ACL específicas ni cambios posteriores de permisos.

E4: muestra de actividad. Un trabajo escribió un resumen; un revisor lo leyó. No hay más registros. El expediente no documenta todos los archivos temporales de preparación, accesos históricos ni rutas alternativas de salida.

PrediceLa entrada de Maya dice lectura/escritura. ¿Establece E2 que puede escribir el resumen antiguo?

No. Su entrada de usuario coincidente queda limitada por la máscara de solo lectura. Actualmente concede lectura, acorde con su requisito temporal. Ampliar esa máscara compartida también afectaría a otras entradas, incluida la escritura indicada para TempCrew.

Etapa 2: separa dos hallazgos diferentes

E2 concede lectura efectiva a TempCrew mediante su entrada de grupo limitada por la máscara. La entrada other también concede lectura y no está limitada por esa máscara. Ambas exceden E1. E4 no muestra el uso de esos permisos, pero faltar en una muestra no elimina una concesión ni demuestra que nadie la utilizara antes.

E3 produce 0640 bajo las condiciones indicadas: propietario con lectura/escritura, grupo con lectura y otros sin permisos. Coincide con la audiencia aprobada para resúmenes futuros, incluida la exclusión de Maya. Deja E2 intacta. Distingue también la máscara de creación del proceso de la máscara ACL: gobiernan decisiones diferentes aunque compartan la palabra «máscara».

Revela una propuesta modelo de corrección

Para legacy-summary, propone conservar lectura/escritura del propietario, lectura de reviewers y lectura de Maya hasta el viernes. Elimina la entrada de TempCrew y la lectura de other, conserva la máscara ACL de solo lectura y limita la entrada indicada de Maya a lectura. Ese ajuste no reduce su acceso efectivo actual; evita que su bit de escritura sin efecto pase a conceder escritura si después cambia la máscara.

Para resúmenes futuros, conserva el resultado previsto de E3 y verifica por separado el comportamiento real del servicio. No añadas a Maya a reviewers para simplificar esta excepción de un archivo: ampliaría su acceso más allá de E1. Nina aprueba alcance y vencimiento; Leo se responsabiliza de programar implementación y verificación. Registra como seguimiento explícito la retirada de la excepción de Maya después del viernes.

Etapa 3: define qué contaría como éxito

En un entorno de validación aprobado con contenido sintético, exige que archive-worker conserve lectura/escritura y reviewers, lectura. La lectura de Maya del archivo antiguo antes del vencimiento debe funcionar y su escritura, denegarse. TempCrew y una identidad ordinaria no aprobada deben recibir denegación de acceso al contenido. Confirma la audiencia separada de los resúmenes futuros. Conserva identificadores de objetos, contexto de identidad, ACL revisadas y resultados como evidencia.

PrediceEl siguiente resumen supera las comprobaciones para archivos nuevos. ¿Puedes cerrar también el hallazgo de legacy-summary?

No. El éxito con un objeto nuevo no verifica la ACL de uno existente. Registra ambos resultados de aceptación por separado y mantén abierto el hallazgo antiguo hasta cumplir sus criterios.

Expón los límites: el expediente no establece divulgación histórica ni permisos de ubicaciones temporales y cambios de entradas de directorio. Asigna responsables. Prevé una recuperación aprobada si el cambio interrumpe trabajo legítimo, sin aceptar permanentemente la restauración del acceso amplio. La corrección debe conservar el trabajo útil y mostrar sus límites.