¿Por qué Linux / POSIX tiene lchown pero no lchmod?

Parece que Linux admite cambiar el propietario de un enlace simbólico (es decir lchown), pero no se admite cambiar el modo / permiso de un enlace simbólico (es decir lchmod) . Por lo que puedo ver, esto está de acuerdo con POSIX. Sin embargo, no entiendo por qué uno apoyaría cualquiera de estas operaciones pero no ambas. ¿Cuál es la motivación detrás de esto?

linux permissions posix

— Florian Brucker
fuente

Los permisos de un enlace simbólico son siempre lrwxrwxrwx. A chmodno tiene sentido aquí. Seguir el enlace lo lleva a los permisos de destino.

— ott--

@ott: en Linux, los permisos de un enlace simbólico son siempre los que usted otorgó precisamente porque Linux no es compatible lchmod. Pero otros sistemas operativos tipo Unix sí lo admiten (por ejemplo, Mac OS X ), por lo que la pregunta es por qué Linux no lo hace cuando sí lo es lchown.

— Florian Brucker

Respuestas:

Linux, como la mayoría de los sistemas tipo Unix (Apple OS / X es una de las raras excepciones), ignora los permisos en los enlaces simbólicos cuando se trata de resolver sus objetivos, por ejemplo.

Sin embargo, la propiedad de los enlaces simbólicos, como otros archivos, es relevante cuando se trata del permiso para renombrar o desvincular sus entradas en directorios que tienen el tbit establecido, como /tmp.

Para poder eliminar o cambiar el nombre de un archivo (enlace simbólico o no) /tmp, debe ser el propietario del archivo. Esa es una razón por la que uno podría querer cambiar la propiedad de un enlace simbólico (para otorgar o eliminar permisos para desvincularlo / renombrarlo).

$ ln -s / /tmp/x
$ rm /tmp/x
# OK removed

$ ln -s / /tmp/x
$ sudo chown -h nobody /tmp/x
$ rm /tmp/x
rm: cannot remove ‘/tmp/x’: Operation not permitted

Además, como mencionó Mark Plotnick en su respuesta ahora eliminada , las aplicaciones de copia de seguridad y archivo deben lchown()restaurar los enlaces simbólicos a sus propietarios originales. Otra opción sería cambiar euid y egid antes de crear el enlace simbólico, pero eso no sería eficiente y complicaría las gestiones correctas en el directorio en el que se extrae el enlace simbólico.

— Stéphane Chazelas
fuente

No estoy seguro de si esta es la motivación original, pero da una razón por la cual el diseño es útil. ¡Gracias!

— Florian Brucker

No hay lchmod () en posix pero fchmodat () que permitiría establecer los permisos de un enlace simbólico. Esto todavía no requiere que se evalúen los permisos de los enlaces simbólicos.

— astuto
fuente

OP sabe que no tener lchmodestá de acuerdo con POSIX. ¿Qué agrega esta respuesta que aún no está en la pregunta?

— muru

El operador preguntó por qué solo se admite una de las funciones y le expliqué que prácticamente ambas están disponibles, pero no con el nombre mencionado.

— schily

¿Cómo es eso? El estándar dice : algunas implementaciones pueden permitir cambiar el modo de los enlaces simbólicos. Esto no es compatible con las interfaces en la especificación POSIX. Los sistemas con dicho soporte proporcionan una interfaz llamada lchmod (). Para soportar tales implementaciones, fchmodat () tiene un parámetro flag. Todo lo que dice es que hay una bandera para fchmodat que permite que la implementación cambie los permisos de enlaces simbólicos. No es que necesariamente pueda.

— muru

Correcto, dado que los permisos de los enlaces simbólicos no se evalúan desde hace 35 años, no tiene sentido cambiar los modos. Fchmodat () existe para ortogonslity. La única ventaja real era futimensat (), ya que las marcas de tiempo configurables para los enlaces simbólicos ayudan a los humanos a comprender un árbol de directorios.

— schily

@schilly, OS / X respeta los permisos en enlaces simbólicos. Allí, si no tiene permisos de lectura, no puede resolver sus objetivos.

— Stéphane Chazelas