¿Cómo se aplican los permisos de archivo a los enlaces simbólicos?

Digamos que tienes esta estructura:

+ directory
-- file1
-- file2
-- file3 -> /tmp/file3

file3es un enlace a otro file3en otro lugar del sistema.

Ahora digamos que chmod 777el directorio y todos los contenidos dentro de él. ¿Mi file3en /tmprecibir los permisos? Además, digamos que tenemos la misma situación pero invertida.

/tmp/file3 -> /directory/file3

Si aplico los permisos en el archivo al que está vinculado, ¿cómo afecta eso al enlace?

Depende de cómo llame chmody la plataforma en la que se esté ejecutando.

Por ejemplo, en un sistema Linux, man chmoddice esto:

chmod nunca cambia los permisos de los enlaces simbólicos; la chmod llamada al sistema no puede cambiar sus permisos. Esto no es un problema ya que los permisos de los enlaces simbólicos nunca se usan. Sin embargo, para cada enlace simbólico que aparece en la línea de comando, chmodcambia los permisos del archivo señalado. Por el contrario, chmodignora los enlaces simbólicos encontrados durante los recorridos recursivos del directorio.

Sin embargo, en una Mac, chmod se puede usar para modificar los permisos de un enlace simbólico usando opciones como esta (desde man chmod):

-h Si el archivo es un enlace simbólico, cambie el modo del enlace en lugar del archivo al que apunta el enlace.

Por el bien de ejemplo, supongamos que está en una máquina Linux para el resto de esta respuesta.

Si en el primer caso se ejecuta chmod -R 777 directorypara cambiar recursivamente los permisos, el destino del enlace no se verá afectado, pero si lo hace chmod 777 directory/*, lo hará.

Si cambia los permisos en el destino del enlace directamente, esos permisos se mantendrán (ya que, como dicen la página de manual y baraboom , los permisos de enlace reales no se usan para nada).

Registro de prueba para ilustración:

$ mkdir dir && touch dir/file{1,2} /tmp/file3 && ln -s {/tmp,dir}/file3
$ ls -l dir/* /tmp/file3
-rw-r--r-- 1 user group  0 2011-06-27 22:02 /tmp/file3
-rw-r--r-- 1 user group  0 2011-06-27 22:02 dir/file1
-rw-r--r-- 1 user group  0 2011-06-27 22:02 dir/file2
lrwxrwxrwx 1 user group 10 2011-06-27 22:02 dir/file3 -> /tmp/file3

$ chmod -R 777 dir && ls -l dir/* /tmp/file3
-rw-r--r-- 1 user group  0 2011-06-27 22:02 /tmp/file3
-rwxrwxrwx 1 user group  0 2011-06-27 22:02 dir/file1
-rwxrwxrwx 1 user group  0 2011-06-27 22:02 dir/file2
lrwxrwxrwx 1 user group 10 2011-06-27 22:02 dir/file3 -> /tmp/file3

$ chmod 700 dir/* && ls -l dir/* /tmp/file3
-rwx------ 1 user group  0 2011-06-27 22:02 /tmp/file3
-rwx------ 1 user group  0 2011-06-27 22:02 dir/file1
-rwx------ 1 user group  0 2011-06-27 22:02 dir/file2
lrwxrwxrwx 1 user group 10 2011-06-27 22:02 dir/file3 -> /tmp/file3

las respuestas de baraboom y peth son correctas: los bits de permiso en los enlaces simbólicos en sí mismos son irrelevantes (excepto en macOS; ver más abajo), y cambiar el permiso en un enlace simbólico, por la chmodherramienta de línea de comandos o por la chmod()llamada al sistema, simplemente actuará como si se realizó contra el objetivo del enlace simbólico.

Para citar la descripción de SUSv4 / POSIX.1-2008 de la llamada al sistema symlink () :

Los valores de los bits de modo de archivo para el enlace simbólico creado no están especificados. Todas las interfaces especificadas por POSIX.1-2008 se comportarán como si el contenido de los enlaces simbólicos se pudiera leer siempre, excepto que el valor de los bits de modo de archivo devuelto en el campo st_mode de la estructura estadística no está especificado.

Aquí, "no especificado" deja margen de interpretación para cada implementación. Detalles específicos:

• En Linux (probado con ext4fs), stat()devuelve st_mode=0777, sin importar cuál era la máscara de usuario cuando se creó el enlace simbólico; ls -lpor lo tanto, siempre se muestra lrwxrwxrwxpara enlaces simbólicos.
• En macOS (HFS) y FreeBSD (UFS y ZFS), un enlace simbólico tiene su propio permiso: el chmod -hcomando mencionado anteriormente puede cambiar este permiso de enlace (que utiliza internamente una lchown()llamada al sistema no POSIX para lograr esto), y el stat()sistema la llamada devuelve este valor para st_mode.

Los enlaces simbólicos en Linux y FreeBSD siempre se pueden seguir, según lo especificado por POSIX. En particular, en FreeBSD, esto significa que el modo de archivo de un enlace simbólico no tiene ningún efecto en el control de acceso.

Por otro lado, macOS rompe ligeramente POSIX. Aunque se puede seguir un enlace simbólico independientemente de su permiso de lectura, readlink()falla con EACCES(Permiso denegado) si el usuario no tiene permiso de lectura:

$ sudo ln -shf target symlink
$ sudo chmod -h 444 symlink
$ ls -l symlink
lr--r--r--  1 root  staff  1 Mar 14 13:05 symlink -> target
$ sudo chmod -h 000 symlink
$ ls -l symlink

ls: symlink: Permission denied
l---------  1 root  staff  1 Mar 14 13:05 symlink
$ echo kthxbye > target
$ cat symlink
kthxbye

(Tenga en cuenta que -> targetfalta la parte en la salida del segundo ls -lcomando, y que cat symlinkaún así tuvo éxito e imprimió el contenido del targetarchivo a pesar de que el usuario no tenía permiso de lectura symlink).

NetBSD aparentemente ofrece una opción de montaje especial llamada sympermque, si se establece, provoca que los permisos de lectura / ejecución de enlaces simbólicos controlen readlink()y atraviesen los enlaces.

1. suelte el archivo de enlace (después de asegurarse de que ningún proceso lo use)
2. configure umask de tal manera que el 777-umask = permisos de archivo requeridos
3. crear el archivo de enlace de nuevo