¿Por qué los archivos no pueden manipularse mediante inode?

¿Por qué no puede acceder a un archivo cuando solo conoce su inodo, sin buscar un archivo que enlace a ese inodo? Un enlace directo al archivo no contiene nada más que un nombre y un número que le indica dónde encontrar el inodo con toda la información real sobre el archivo. Me sorprendió cuando me dijeron que no había modo de modo de usuario para usar el número de inode directamente para abrir un archivo.¿Por qué los archivos no pueden manipularse mediante inode?

Parece una función tan inofensiva y útil para el sistema. ¿Por qué no se proporciona?

Fuente

2011-01-05 Null Set

¿Cuál es el caso de uso de hacer esto? – user562374

@user La pregunta fue inspirada por esta pregunta. http://stackoverflow.com/questions/4605851/how-to-get-directory-name-by-inode-value-in-c También podría ver que se utiliza para pasar un archivo a otro usuario que tiene acceso a la archivo pero no tiene acceso a mi estructura de directorio. –

Esa es exactamente la razón por la que no está permitido. Si se permitía el acceso a los archivos por número de inodo, simplemente podría probar cada número de inodo y omitir todos los permisos de directorio. –

Algunos sistemas operativos hacen tienen esa facilidad. Por ejemplo, OS X lo necesita para admitir el Carbon File Manager, y en Linux puede usar debugfs. Por supuesto, puede hacerlo en cualquier UNIX desde la línea de comandos a través del find -inum, pero la verdadera razón por la que no puede acceder a los archivos por inodo es que no es particularmente útil. Es tipo de evitar los permisos de archivo, porque si hay un archivo que puede leer en una carpeta que no puede leer o ejecutar, entonces abrir el inode le permite descubrirlo.

La razón de que no es muy útil es que es necesario encontrar un número de inodos a través de una llamada *stat(), en el que apuntar que ya tienen el nombre del archivo (o un fd abierto) ... o si tiene que adivinar el inum.

Fuente

2011-01-05 17:19:50

Ah, pero si cierra el archivo y luego quiere volver a abrirlo más tarde, no tendría que registrarlo. – johnnycrash

@johnnycrash ¿Qué te puede sacar? No se puede hablar de una ganancia de rendimiento significativa ya que está a punto de usar un archivo en un medio de almacenamiento realmente lento. –

@ johnnycrash no estarías seguro de que estarías abriendo el mismo archivo en realidad: el mismo inodo podría haber sido destruido y reutilizado por el sistema de archivos para un nuevo archivo, y no tendrías manera de comprobar si eso pasó. – pqnet

Motivos de seguridad: para acceder a un archivo, necesita permiso en el archivo ASÍ COMO permiso para buscar en todos los directorios desde la raíz necesaria para acceder al archivo. Si pudiera acceder a un archivo por inode, podría omitir las comprobaciones en los directorios que lo contienen.

Esto le permite crear un archivo al que puedan acceder un conjunto de usuarios (o un grupo de grupos) y nadie más - crear directorios que solo sean accesibles por los usuarios (un directorio por usuario), y luego vincular el archivo en todos esos directorios; el archivo en sí es accesible por cualquier persona, pero solo puede accederlo alguien que tenga permisos de búsqueda en uno de los directorios a los que está vinculado.

Fuente

2011-01-05 17:09:15

Una capacidad hipotética para acceder a archivos por número de inodo podría restringirse a 'root'. –

Respondiendo a su comentario: Para "pasar un archivo", puede usar fd pasando por sockets AF_LOCAL por medio de SCM_RIGHTS (vea man 7 unix).

Fuente

2011-01-05 17:12:25 user502515

Btrfs tiene un ioctl para eso (BTRFS_IOC_INO_PATHS added in this patch), sin embargo, no intenta verificar los permisos a lo largo de la ruta y simplemente se reserva para el directorio raíz.

Fuente

2012-09-30 16:31:28 Gabriel

Seguramente si ya ha buscado un archivo a través de una ruta de acceso, ¿no debería tener que hacerlo una y otra vez?

stat(f,&s); i=open(f,O_MODE);

implica dos arrastres a través de una estructura de directorio. Esto desperdicia ciclos de CPU con operaciones de cadena innecesarias. Sí, el caché fs bien diseñado reducirá la mayor parte de esta ineficiencia de un usuario final casual, pero repetir el trabajo sin ninguna razón es feo, si no simple.

Fuente

2013-05-18 05:30:34

Almacena el inode en la base de datos y evita algunos ciclos de acceso, esto es docenas de milisegundos, no nanosegundos para operaciones de cadena. 1000 veces más rápido, especialmente si ordena los números de inodos. – Lothar

Esto me está dando algunas ideas. El comentario de @Lothar está justo en el lugar: si omite el uso de nombres a través del sistema de archivos, básicamente tiene que implementar algún equivalente usando una base de datos. Si abre los mismos archivos una y otra vez y desea que el único problema real sea evitar analizar millones en archivos en el mismo directorio una y otra vez ... ¿solución? simplemente enlace a estos archivos en un directorio que contenga muchos menos archivos. Esto evitará la mayoría de los ciclos de CPU perdidos, básicamente haciendo casi lo mismo que acceder por inodo. – kriss

¿Por qué los archivos no pueden manipularse mediante inode?

Respuesta

Cuestiones relacionadas