Cortar / pegar archivo entre carpetas ya no conserva los permisos de carpeta originales


3

En las unidades NTFS, el comportamiento solía ser que, cuando se movía un archivo, retendría los permisos del archivo original, si el movimiento se hacía a una carpeta en el mismo volumen.

Lo sé por experiencia y se puede ver aquí: https://support.microsoft.com/en-us/kb/310316

Pero hoy estaba tratando de mostrar este comportamiento a un colega y simplemente no funcionó. Cada vez que el archivo simplemente tendría los permisos de la nueva carpeta asociada a él.

He probado en 3 máquinas diferentes y ya no funciona así. ¿Cuándo cambió? Y no, la configuración de registro mencionada anteriormente no está establecida.

¿Alguna idea de cuándo esto cambió?

[Editar]

Solo un ejemplo para hacerlo más claro

Supongamos que tengo estas carpetas en mi unidad C.

  • C: \ Compartido
    • \Trabajando
    • \Final

Y tengo cuatro grupos: - Pasantes - Empleados - Gerentes - Personal (que tiene los 3 anteriores como miembros).

Ahora, consideremos los permisos (simplificados).

  • C: \ Compartido
    • No hereda
    • Permite explícitamente el control total a los administradores
    • Permite explícitamente Modificar a gerentes
  • C: \ Shared \ Working
    • Hereda de Compartido
    • Permite explícitamente Modificar a empleados
  • C: \ Compartido \ Final
    • Hereda de Compartido
    • Permite explícitamente Leer al personal

Ahora, supongamos que tengo un archivo en la carpeta de trabajo, llamado Bullshit.doc.

Anteriormente, si el archivo se movía (cortaba / pegaba) de la carpeta Trabajando a la carpeta Final, retendría los permisos originales, es decir, los Gerentes y el Personal podrían modificar y los pasantes no tendrían permisos.

Ahora, cuando intento mover el Bullshit.doc, cuando lo muevo, simplemente heredará los permisos de la carpeta Final, es decir, simplemente perdona que los pasantes no tengan acceso.

Mi pregunta es: esto cambió, ¿no? ¿O me estoy volviendo loco? Estoy 99% seguro de que funcionó tal como se describe en la KB.

Sé que tuve problemas similares a esto en el pasado, cuando los usuarios de nivel superior movían archivos entre carpetas (con diferentes conjuntos de permisos) y luego se quejaban de que los pasantes no podían leer los archivos. Tuve que explicar más de una vez que cortar / pegar no funcionaría, que necesitan copiar / pegar / eliminar. Estaba seguro en Windows 2003, pero podría ser al menos 2008 R2.

[Editar 2] Ahora con fotos !!!

Ok, entonces decidí probar y replicar. Con los archivos reales y no ejemplos simples. Aquí está...

Entonces esta es la carpeta de origen. Vea todos los permisos implícitos y el único permiso explícito. Alguna carpeta

Ahora, creemos un archivo allí. Y verifique los permisos.Solo un documento al azar

Hora de mover el archivo al destino. La carpeta original era solo una carpeta temporal. Verifiquemos los permisos de la carpeta de destino. Permisos mucho menos complicados

Después de mover la carpeta, verifiquemos sus permisos ... WTAF !!!

Hum ... no es lo que esperaría. Incluso si fuera solo un archivo, por lo que reuní en el KB anterior, debería mantener los permisos. Y así es como recuerdo que se comportó.

Pero parece que cambió. Y no puedo encontrar una fuente oficial de cuándo sucedió.

Esto me hace dudar de mi cordura.


La herencia de permisos puede anular este comportamiento. Si la nueva carpeta hereda, el contenido no corta explícitamente la herencia, y los contenedores de origen y destino no heredan de la misma lista de ACL, habrá diferencias en los permisos resultantes. También tenga en cuenta que la Protección de recursos de Windows (el mecanismo que permite a UAC solicitar junto con los permisos) requiere una mayor variación en las ACL de permisos en todo el sistema de archivos (por ejemplo, los archivos de programa y los directorios de Windows no heredan de C, y los hogares de los usuarios tienen diferencias) permisos no heredados).
Frank Thomas

Agregué un ejemplo, para aclarar. Realmente no creo que tenga nada que ver con la herencia de permisos.
Luiz Angelo

Respuestas:


2

NTFS todavía está evolucionando y cambiando. Creo que los cambios en el manejo de los permisos heredados aparecieron por primera vez en Vista y evolucionaron aún más en Windows 7. La configuración del registro en su enlace data de XP, por lo que sé, se ignora en las versiones más recientes.

Para comprender lo que sucede cuando uno copia / mueve un archivo, primero debe comprender la diferencia entre los permisos implícitos y explícitos.

Los permisos implícitos se heredan de la carpeta principal, por lo que se almacenan con la carpeta principal. No se almacenan con los niños y, por lo tanto, no se pueden mover / copiar. En otras palabras, estos permisos solo se aplican mientras el elemento secundario está en su carpeta principal, porque provienen del elemento primario.

Los permisos explícitos se otorgan manualmente a la carpeta / archivo y se almacenan en las Listas de control de acceso (ACL) como atributos NTFS. Se puede considerar que pertenecen al elemento y, en algunos casos, se pueden mover con él si el sistema de archivos de destino también es NTFS.

Algunas consecuencias de esta arquitectura NTFS son:

  • Cuando se copia una carpeta / archivo , se crean nuevas entradas de destino en las tablas NTFS de la carpeta de destino. Por lo tanto, el archivo copiado perderá todos los permisos explícitos y solo se heredará de su nueva carpeta principal.
  • Cuando un archivo / carpeta se mueve dentro del mismo volumen , se mueve su entrada NTFS, completa con todos los atributos y permisos contenidos. Por lo tanto, retendrá todos los permisos explícitos, pero perderá sus permisos heredados antiguos, obteniendo en cambio los de su nueva carpeta principal.
  • Cuando una carpeta / archivo se mueve entre diferentes volúmenes , el movimiento se trata como una copia y no conservará ninguno de los permisos originales. La única diferencia con respecto a la copia es que la fuente se elimina cuando se completa la copia.
  • Un archivo / carpeta que solo tiene permisos heredados, no tiene permisos para moverse. Tal elemento siempre heredará sus permisos de la carpeta principal.
  • Una carpeta / archivo puede marcarse como permisos no heredados de su padre. En ese caso, todos sus permisos se almacenan con él como ACL, es decir, como permisos explícitos.

Esto va en contra de la documentación más establecida, donde generalmente se afirma que cuando una carpeta / archivo se mueve dentro del mismo volumen, retendrá sus permisos NTFS originales, tanto implícitos como explícitos. Esto tal vez alguna vez fue cierto en versiones anteriores de Windows, pero fue verificado por mí y por el póster que ya no es el caso de los permisos implícitos en Windows 7 y Windows 10.

Para ver un ejemplo de reglas de movimiento documentadas erróneamente, consulte el artículo Cómo se manejan los permisos de archivos y carpetas al mover o copiar archivos en Windows 2008 R2 y Windows 7 . Este artículo fue la fuente de mi discusión a continuación con el póster, donde descubrimos juntos las verdaderas reglas que rigen copiar y mover en NTFS.


Hola Harry. Intenté aplicar las reglas al ejemplo que di, y se comporta de manera diferente. Las reglas establecidas anteriormente son exactamente cómo creo que se comportaría. Pero cuando trato de reproducirlo termina ignorando los permisos explícitos. ¿Has intentado aplicar las reglas al ejemplo dado?
Luiz Angelo

Necesita definir su caso exactamente. Pero como se indicó anteriormente, el hecho de que un archivo esté en una carpeta no significa que los permisos de la carpeta se moverán con él, solo los permisos otorgados explícitamente al archivo en sí , o otorgados a la carpeta pero con propagación a los hijos (la propagación solo funciona para los archivos existentes y los nuevos solo heredarán).
harrymc

Pensé que el caso de ejemplo era bastante claro. De todos modos, intenté con carpetas y permisos explícitos. Cuando se movió, la carpeta no retuvo los permisos originales. Supongo que editaré la pregunta más tarde con fotos y ejemplos.
Luiz Angelo

¿Es su caso un movimiento en el mismo volumen? ¿Y qué versión de Windows? Sí, algunos ejemplos de permisos no retenidos serían útiles.
harrymc

¿Y estás moviendo archivos o una carpeta?
harrymc

1

Hay un detalle adicional importante para agregar a la excelente y completa explicación de harrymc, y este detalle termina causando un comportamiento dividido, donde un movimiento de archivo a veces se comporta en el estilo 2003 y otras en el estilo 2008.

La manera en que los movimientos dentro del volumen NTFS se actualizaron en 2008 / Vista y superior no es una revisión completa, sino que solo agrega un segundo paso en segundo plano.

Paso 1) MFT se actualiza; el archivo se mueve y retiene los permisos originales
(al igual que en 2003 / XP y anteriores. Los movimientos en esos sistemas operativos se detienen en este paso).

Paso 2) Las ACL se actualizan para eliminar los permisos heredados de la carpeta principal original y aplicar los permisos heredados de la nueva carpeta principal.
(Este es el paso adicional que 2008 / Vista agregó para que los archivos tengan los permisos de la carpeta de destino).

Sin embargo, si el usuario que realiza el movimiento tiene derechos de modificación y no tiene explícitamente los permisos de cambio correctos, el paso 2 fallará (pero no se lo dirá), y terminará con el comportamiento de la vieja escuela, por lo que parece que las cosas están de vuelta en 2003 de nuevo.

En este mismo escenario, si alguien copia el archivo y luego elimina el original (de la misma forma en que el sistema de archivos maneja un movimiento entre volúmenes), todo funciona de la manera que usted esperaría.

No hay ninguna solución elegante: puede otorgar a los usuarios derechos de Cambiar permisos para que el Paso 2 pueda tener éxito, o cualquier archivo movido entre carpetas de permisos diferentes en el mismo volumen del servidor de archivos conservará sus permisos originales hasta que se vuelvan a propagar por la fuerza.


Esta es una adición a una respuesta existente y no una respuesta en sí misma. Por favor publícalo como un comentario.
wp78de
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.