¿Cómo solucionar el defecto de diseño Mover / Copiar NTFS?

31

Como cualquiera que haya tratado con los permisos del servidor de archivos es consciente, NTFS tiene una característica / falla de diseño interesante conocida como el problema Mover / Copiar.

Como se explica en este artículo de MS KB , los permisos para una carpeta o archivo no se heredan automáticamente del padre si la carpeta se mueve y el origen y el destino están en el mismo volumen NTFS. Los permisos se heredan si la carpeta se copia o si el origen y el destino están en volúmenes diferentes.

Aquí hay un ejemplo rápido:

Tiene dos carpetas compartidas en el mismo volumen NTFS llamadas "Técnicos" y "Gerentes". El grupo de Técnicos tiene acceso RW a la carpeta Técnicos y el grupo de Gerentes tiene acceso RW a la carpeta "Administradores". Si alguien tiene acceso a ambos y mueve una subcarpeta de la carpeta "Administradores" a la carpeta "Técnicos", la carpeta que se mueve todavía solo es accesible para los usuarios en el grupo "Administradores". El grupo "Técnicos" no puede acceder a la subcarpeta aunque se encuentre en la carpeta "Técnicos" y deba heredar los permisos de la parte superior.

Como puede imaginar, esto provoca llamadas de asistencia, tickets y ciclos desperdiciados al resolver estos problemas de usuario final, sin mencionar el conjunto de permisos de ratas con los que puede terminar si los usuarios mueven carpetas entre diferentes carpetas / áreas seguras en el mismo volumen

Las preguntas son:

¿Cuál es la mejor manera de solucionar este error de diseño de NTFS y cómo lo maneja en su entorno?

Sé que el artículo de KB vinculado habla sobre algunas claves de registro para cambiar el comportamiento predeterminado del Explorador de Windows, pero son del lado del cliente y requieren que los usuarios tengan la capacidad de cambiar los permisos, lo que creo que en la mayoría de los entornos no es un iniciador si desea mantener el control sobre los permisos del servidor de archivos (y su cordura como administrador de sistemas).

permissions filesystems ntfs access-control-list David Archer
fuente
2
Sé que el ejemplo de Gerentes / Técnicos es solo para ilustrar la falla, pero en algunos casos ese es el comportamiento que desearías: si alguien mueve accidentalmente la carpeta de Gerentes a Técnicos, probablemente no quieras que los Técnicos puedan acceder eso.
Ward - Restablece a Monica
2
Esto realmente no es un defecto, esta es la forma en que funcionan los permisos de archivos. Se ha documentado desde el lanzamiento de NTFS. No puedo creer que algunas personas recomienden no usar permisos de archivo y solo usar permiso de compartir para controlar el acceso. Esto va en contra de los conceptos básicos de seguridad para un servidor de archivos de Microsoft. La razón por la que no se hereda mover una carpeta / archivo en el mismo volumen es porque la carpeta / archivo en realidad no se mueve en el disco, solo el puntero vemos cambios.
Michael Brown

Respuestas:

12

Mi enfoque es no usar permisos de archivo a nivel de archivo / directorio; use permisos de nivel de uso compartido de archivos y configure toda la unidad de datos del sistema de archivos del servidor en Control total para todos (que se convierte en discutible).

Con los años (más de 10), descubrí que los permisos NTFS son más complejos y generan más errores. Si los permisos están configurados incorrectamente, o la herencia se rompe, expone los datos y es difícil de encontrar y ver. Además, está expuesto al problema de mover / copiar como usted dice.

Lugares donde tiene que usar directorios / archivos de nivel de ACL; No conozco otra solución que el control de la salud de forma regular.

James Risto
fuente
10

Bueno, en realidad no es un defecto. Esta regla para manejar permisos cuando se mueven archivos ha estado vigente desde al menos la versión beta 2 de NT3.1 (aunque obviamente no es herencia ya que solo se agregó con Windows 2000). Es casi tan conocido como cualquier característica de Windows. Tengo mucha simpatía por su punto de vista, ya que puede haber pocos de nosotros que no hayan sido quemados por esto en una etapa. Pero es algo que el administrador del sistema aprende rápidamente.

JR

John Rennie
fuente
66
Tuve una discusión con Raymond Chen en su blog sobre esto. Microsoft "vende" NTFS como si tuviera permiso de "herencia", luego retrocede cuando aparece esta grieta particular en la armadura. NTFS tiene herencia de permisos en el momento de la creación del archivo al colocar ACE explícitos en los archivos cuando se crean. Yo diría que, siempre que la documentación y la literatura de marketing hablen sobre su sistema de herencia como si fuera en tiempo real, la documentación o el código tienen errores. Deberían elegir uno y arreglarlo.
Evan Anderson
1
Bueno, es una compensación. Si la herencia fuera en tiempo real, cada vez que abriera un archivo en la parte inferior de un árbol profundo, el sistema operativo tendría que ejecutar el árbol para averiguar cuáles son los permisos efectivos. Por supuesto, la compensación es que si cambias los permisos en la parte superior de un árbol profundo, ¡tienes muuuy espera! ¿Active Directory no usa el mismo modelo?
John Rennie
Los objetos AD heredan correctamente los permisos del nuevo padre cuando se mueven entre contenedores y yo diría que este es el comportamiento "correcto" esperado al mover archivos / carpetas en NTFS.
David Archer
3
@renniej: AD usa una verdadera herencia en tiempo real. El sistema de archivos Netware lo hizo hace mucho tiempo. NTFS también podría haberlo hecho si Microsoft lo hubiera implementado. Es el "camino no tomado". Lo que me molesta es que la documentación de Microsoft re: NTFS y Explorer "se reproduce" como si la herencia fuera en tiempo real (es decir, mentiras). ¡Díganos como es o corrija el comportamiento para engañar con la documentación!
Evan Anderson
@renniej Como dijo Evan Anderson, Netware hizo esto en 1990 cuando eran reyes. El problema se puede solucionar creando otro índice del sistema de archivos que rastrea la 'lista de visibilidad'. Microsoft decidió no hacer eso, pero posiblemente podría crear una para una futura versión de Windows Server.
sysadmin1138
6

Hemos estado usando NTFS desde NT 3.51 y aunque hemos visto este "problema" (como casi todos) no nos ha causado muchos problemas:

  • Siempre les decimos a las personas que copien archivos si necesitan moverlos de un directorio compartido a otro. "Mantenga presionada la tecla CTRL al arrastrar y asegúrese de que se muestre el pequeño +", es una frase común.
  • Nuestras carpetas compartidas tienen una estructura bastante simple, y las carpetas compartidas que creamos no se cruzan entre grupos con demasiada frecuencia, por lo que es más probable que las personas quieran copiar archivos en primer lugar.
  • Vemos el problema principalmente en nuestro espacio "común": carpetas donde todos pueden leer / escribir, pero esos directorios son en su mayoría de corta duración, por lo que el problema desaparece cuando se eliminan.
Ward - Restablece a Monica
fuente
4

Soluciones alternativas en las que puedo pensar:

  • encuentre alguna forma de hacer que las carpetas con diferentes permisos estén en diferentes volúmenes NTFS
  • Realice una tarea programada (una vez por hora o una vez por día, dependiendo de la frecuencia de las solicitudes de soporte) que se ejecuta a través de las carpetas y restablece todos los permisos para que sean los mismos que los del nivel superior. Esto es menos que ideal, más aún si las carpetas tienen muchos archivos, pero es algo que mantendría el problema solucionado si no hay una buena solución, como una solución de registro del lado del servidor. El comando que querrá ver se llama 'cacls', que luego puede agregar a un archivo por lotes.

Descargo de responsabilidad: vengo de un fondo de Unix (y he implementado el último para corregir diferentes fallas de permisos: se siente desagradable, pero hace el trabajo), por lo que puede haber una solución mucho mejor.

marca
fuente
+1: la primera respuesta que da Mark es la mejor opción. Es un dolor, pero es la mejor manera de evitar esta estúpida decisión de diseño en NTFS 5.
Evan Anderson
Para expandir: ¡Este es un lugar donde mis amigos que usan SharePoint dirían "usar SharePoint"! Del mismo modo, mis amigos de control de versión y amigos de sistema de control de documentos apuntarían a Subversion, Documentum, etc., y dirían "use eso". Esta elección de diseño en NTFS es una gran verruga enorme, y casi te hace preguntarte si Microsoft realmente usa su propio software cuando tienes que luchar con él en tu propia red. (Me grita que Microsoft no usa su software de la misma manera que lo hacemos con nuestros usuarios, en realidad. Debe ser agradable tener una compañía llena de "trabajadores del conocimiento".)
Evan Anderson
1
Estoy de acuerdo en que idealmente podríamos separar todas las carpetas compartidas en sus propios volúmenes, en la práctica esto no es viable para un entorno grande (miles de carpetas compartidas). Además, sin algún punto de unión funky o vudú de enlace simbólico, esto significa perder la capacidad de tener subcarpetas anidadas con diferentes permisos sobre ellas.
David Archer
1
@David: mover los datos a través de recursos compartidos dará como resultado una copia y eliminación. Mover datos dentro de un recurso compartido dará como resultado un movimiento. Si convierte cada carpeta compartida en la raíz de una jerarquía de permisos sin subcarpetas con permisos más restrictivos, aliviará el problema. Aún feo, sin embargo. (Tengo un servidor W2K3 con más de 2200 carpetas compartidas individuales y no veo problemas de rendimiento ...)
Evan Anderson
3

Cuando me mudo como administrador, uso xcopy / s / e / c / h / r / k / y, todo, aparte de la propiedad del archivo y ACL, lo que significa que la herencia de ACL se activa automáticamente. Nunca tuve que lidiar con una situación en la que un usuario movido cosas sin embargo.

Maximus Minimus
fuente
2
¿Tus usuarios están vivos?
Evan Anderson
44
A veces me pregunto ...
Maximus Minimus
@ Incluso: ¡Quizás ninguno de ellos esté en dos grupos!
SamB
+1 para guiar a la gente a la herramienta que resuelve este problema al mantener archivos (junto con muchos otros); sin embargo, XCOPY se ha depreciado: ROBOCOPY.EXE es su sucesor muy capaz.
jnaab
2
Perdón por la picardía, pero no copia los archivos de copia (en lugar de mover los archivos). Parece que el autor no tiene problemas con la copia, solo tiene problemas con el movimiento. Puede que me equivoque en este caso de falta de experiencia, así que corríjame si me equivoco (es decir, si usa el comando 'del' después de usar 'xcopy', ¡entonces los archivos se copian y eliminan realmente! = movido?)
colemik
3

Uso políticas de grupo / políticas de seguridad / sistema de archivos para realizar un seguimiento de los permisos complicados. (NUNCA use los "permisos de reemplazo" en la política).

Programe un CACLS para restablecer todos los permisos durante la noche seguido de un gpupdate / force para volver a aplicar el permiso de la política. Funciona de maravilla.

Alexandru Nica
fuente
¿Presumiblemente esto es solo para servidores Windows? Como la directiva de grupo debe aplicarse a los objetos de dominio, ¿no podría aplicarse esto a recursos compartidos de almacenamiento que no sean de Windows?
Rich M
2

Desde Windows 7 (o tal vez Windows Vista), los permisos para una carpeta o archivo SÍ heredan del padre si la carpeta se mueve y el origen y el destino están en el mismo volumen NTFS, si un archivo o carpeta se está copiando a través del Explorador. En un sistema operativo anterior, puede usar Far Manager: permite habilitar la herencia de permisos desde el destino (junto con toneladas de otras características). Aunque Far puede parecer poco amigable para un usuario general.

GCRaistlin
fuente
0

Una solución muy simple es simplemente comprimir los archivos y descomprimirlos en el directorio de destino.

Mover
fuente
Acabo de probar esto y desafortunadamente no ha funcionado. Los permisos en el archivo zip son diferentes incluso antes de que haya hecho algo con él. Los permisos heredados permanecen pero no se crean los explícitos.
Rich M