.\" Hey Emacs! This file is -*- nroff -*- source.
.\"
.\" Copyright (C) 1992 Drew Eckhardt;
.\"               1993 Michael Haardt, Ian Jackson.
.\"
.\" Se autoriza hacer y distribuir copias literales de este manual siempre
.\" que el aviso de copyright y este aviso de autorización se preserven en
.\" todas las copias.
.\"
.\" Se autoriza copiar y distribuir versiones modificadas de este manual
.\" bajo las condiciones para copiar literalmente, siempre que todo el trabajo
.\" resultante sea distribuido bajo los términos de un aviso de autorización
.\" idéntico a éste.
.\"
.\" Ya que el kernel y las bibliotecas de Linux están cambiando
.\" constantemente, esta página de manual puede ser incorrecta u obsoleta.
.\" El(Los) autor(es) no asumen ninguna responsabilidad de los errores u
.\" omisiones, o de los daños resultantes del uso de la información contenida
.\" aquí. El(Los) autor(es) pueden no haber tomado el mismo nivel de cuidado en
.\" la producción de este manual, que es licenciado gratuitamente, como el que
.\" podrían haber tomado trabajando profesionalmente.
.\"
.\" Las versiones procesadas o tratadas de este manual que no se acompañen
.\" con los fuentes deben reconocer el copyright y los autores de este trabajo.
.\"
.\" Modificado el Mié, 21 Jul 1993, a las 19:36:29, por Rik Faith (faith@cs.unc.edu)
.\" Modificado el 21 de Ago de 1994 por Michael Chastain (mec@shell.portal.com):
.\"   Se elimina nota sobre viejo kernel (pre-1.1.44) que usaba un
.\"   identificador de proceso incorrecto a lo largo del camino.
.\" Modificado el 18 de Mar de 1996 por Martin Schulze (joey@infodrom.north.de):
.\"   Mejor explicación sobre cómo se comportan con los enlaces simbólicos.
.\" Corregido por Nick Duffek (nsd@bbc.com), aeb, el 26 de Abril de 1996
.\" Modificado el 07 de Sep de 1996 a las 18:17:26 por Michael Haardt:
.\"   Restricciones para NFS
.\" Traducido el 23 de Jul de 1997 por Juan Piernas (piernas@dif.um.es)
.\" Modificado por Joseph S. Myers <jsm28@cam.ac.uk>, 970909
.\" Modified Tue Jan 13 21:21:03 MET 1998 by Michael Haardt:>
.\"   Using access is often insecure       
.\" Modified Tue Oct 16 02:40:48 CEST 2001 by aeb
.\" Modified Tue Apr 23 19:51:15 CEST 2002 by Roger Luethi <rl@hellgate.ch> 
.\" Traducción revisada el Sáb 25 de Abril de 1998 por Juan Piernas <piernas@dif.um.es>
.\" Traducción revisada el Dom 16 de Agosto de 1998 por
.\"   Juan Piernas <piernas@dif.um.es>
.\" Revisado por Miguel Pérez Ibars <mpi79470@alu.um.es> el 17-septiembre-2004
.\"
.TH ACCESS 2 "23 Abril 2002" "Linux" "Llamadas al sistema"
.SH NOMBRE
access \- comprueba los permisos de usuario para un fichero
.SH SINOPSIS
.nf
.B #include <unistd.h>
.sp
.BI "int access(const char *" pathname ", int " mode );
.fi
.SH DESCRIPCIÓN
.B access
comprueba si al proceso se le permitiría leer, escribir o comprobar la
existencia del fichero (u otro objeto del sistema de ficheros) cuyo nombre
es
.IR pathname .
Si
.I pathname
es un enlace simbólico se comprueban los permisos del fichero referenciado
por dicho enlace simbólico.

.I mode
es una máscara compuesta por uno o más de los siguientes elementos:
.BR R_OK ", " W_OK ", " X_OK " y " F_OK .

.BR R_OK ", " W_OK " y " X_OK
se utilizan para la comprobación de lectura, escritura o ejecución del
fichero, respectivamente.
.B F_OK
se utiliza para ver si se permite la mera comprobación de la existencia del
fichero. Esto depende de los permisos de los directorios que aparecen en el
camino hasta el fichero, tal como se da en
.IR pathname ,
y de los permisos de los directorios y ficheros referenciados por los enlaces
simbólicos que se pueden encontrar a lo largo del camino.

La comprobación se realiza con los uid y gid 
.I reales
del proceso, en lugar de utilizar los identificadores efectivos, tal como se
hace cuando realmente se intenta una operación. Esto permite a los programas
con el bit
.BR SETUID
activo determinar fácilmente la autoridad del usuario
invocador.

Sólo se comprueban los bits de acceso, no el tipo de fichero o sus
contenidos. Por lo tanto, si encontramos que un directorio se puede
"escribir", probablemente esto significa que se pueden crear ficheros en el
directorio, no que el directorio se pueda escribir como se hace con un
fichero. Similarmente, podemos encontrar un fichero DOS como "ejecutable"
y, aún así, puede fallar una llamada a
.BR execve (2).

Si el proceso tiene los privilegios apropiados, una implementación
puede indicar éxito para
.B X_OK
aun si ninguno de los bits de permiso de ejecución del fichero están activos.
.SH "VALOR DEVUELTO"
Si ha habido éxito (se han concedido todos los permisos solicitados) la
función devuelve un valor 0. Si se ha producido un error (al menos, uno de
los bits de
.I mode
ha interrogado por un permiso que ha sido denegado, o ha ocurrido algún otro
tipo de error), la función devuelve \-1 y a 
.I errno
se le asigna un valor adecuado.

.SH ERRORES
.B access
fallará si:
.TP
.B EACCES
Se denegaría el acceso solicitado al fichero o se deniega el permiso de
búsqueda para uno de los directorios en
.IR pathname .
.TP
.B ELOOP
Se han encontrado demasiados enlaces simbólicos al resolver
.IR pathname .
.TP
.B ENAMETOOLONG
.IR pathname " es demasiado largo."
.TP
.B ENOENT
Un directorio componente de
.I pathname
es accesible pero no existe o es un enlace simbólico colgado.
.TP
.B ENOTDIR
Un componente usado como directorio en
.I pathname
no es, de hecho, un directorio.
.TP
.B EROFS
Se ha solicitado permiso de escritura para un fichero en un sistema de ficheros
de sólo lectura.
.PP
.B access
puede fallar si:
.TP
.B EFAULT
.IR pathname " apunta fuera del espacio de direcciones al que tiene
acceso."
.TP
.B EINVAL
.IR mode " se ha especificado incorrectamente"
.TP
.B ENOMEM
No hay suficiente memoria disponible en el núcleo.
.TP
.B EIO
Ha ocurrido un error de E/S.
.TP
.B ENOMEM
Memoria del núcleo insuficiente.
.TP
.B ETXTBSY
Se requiere acceso de escritura para un ejecutable que está
siendo ejecutado.
.SH RESTRICCIONES
.B access
regresa un error si falla cualquiera de los tipos de acceso especificados en
la llamada a la función, aunque los otros tipos tuvieran éxito.
.PP
.B access
no puede funcionar correctamente sobre sistemas de ficheros NFS que tengan
activa la aplicación del UID, porque la aplicación del UID se realiza en el
servidor y se oculta a los clientes que comprueban los permisos.
.PP
Usar
.B access
para comprobar si un usuario está autorizado a, por ejemplo, abrir un
fichero antes de que realmente lo haga usando
.BR open (2),
crea un agujero de seguridad ya que el usuario podría explotar el breve
intervalo de tiempo que hay entre la comprobación y la apertura del fichero
para manipularlo.
.SH "CONFORME A"
SVID, AT&T, POSIX, X/OPEN, BSD 4.3
.SH "VÉASE TAMBIÉN"
.BR stat (2),
.BR open (2),
.BR chmod (2),
.BR chown (2),
.BR setuid (2),
.BR setgid (2)