Depende de cómo llames a chmod y la plataforma en la que se está ejecutando.
Por ejemplo, en un sistema Linux, man chmod dice esto:
chmod nunca cambia los permisos de los enlaces simbólicos; el chmod La llamada al sistema no puede cambiar sus permisos. Esto no es un problema ya que los permisos de los enlaces simbólicos nunca se utilizan. Sin embargo, para cada enlace simbólico que aparece en la línea de comando, chmod cambia los permisos del archivo apuntado. Por el contrario, chmod ignora los enlaces simbólicos encontrados durante los recorridos recursivos de directorios.
Sin embargo, en una Mac, chmod se puede usar para modificar los permisos de un enlace simbólico usando opciones como esta (de man chmod ):
-h Si el archivo es un enlace simbólico, cambia el modo del enlace en sí en lugar del archivo al que apunta el enlace.
Por el bien del ejemplo, supongamos que está en una máquina Linux para el resto de esta respuesta.
Si en el primer caso ejecutas chmod -R 777 directory para cambiar recursivamente los permisos, el objetivo 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 del enlace real 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í son irrelevantes (excepto en macOS; ver más abajo) y cambiar el permiso en un enlace simbólico, por el chmod herramienta de línea de comandos o mediante el chmod() llamada al sistema:simplemente actuará como si se realizara contra el objetivo del enlace simbólico.
Para citar la descripción 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 siempre se pudiera leer, excepto que el valor de los bits de modo de archivo devueltos en st_mode campo de la stat la estructura no está especificada.
Aquí, "no especificado" deja espacio para la interpretación de cada implementación. Especificaciones:
- En Linux (probado con ext4fs),
stat()devuelvest_mode=0777, sin importar cuál era el umask cuando se creó el enlace simbólico;ls -lpor lo tanto siempre muestralrwxrwxrwxpara enlaces simbólicos. - En macOS (HFS) y FreeBSD (tanto UFS como ZFS), un enlace simbólico tiene su propio permiso:el
chmod -hEl comando mencionado anteriormente puede cambiar este permiso de enlace (que internamente usa unlchown()que no es POSIX llamada al sistema para lograr esto), y elstat()la llamada al sistema devuelve este valor parast_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 sobre 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 el -> target falta una porción en la salida del segundo ls -l comando, y que cat symlink todavía tuvo éxito e imprimió el contenido del target archivo a pesar de que el usuario no tenía permiso de lectura en symlink .)
NetBSD aparentemente ofrece una opción de montaje especial llamada symperm que, si se establece, hace que los permisos de lectura/ejecución del enlace simbólico controlen readlink() y enlace transversal.