secure_path(3) [netbsd man page]

SECURE_PATH(3)						   BSD Library Functions Manual 					    SECURE_PATH(3)

NAME

     secure_path -- determine if a file appears to be ``secure''

LIBRARY

     System Utilities Library (libutil, -lutil)

SYNOPSIS

     #include <util.h>

     int
     secure_path(const char *path);

DESCRIPTION

     The secure_path() function takes a path name and returns zero if the referenced file is ``secure'', non-zero if not.  Any ``insecurity'',
     other than failure to access the referenced file, will be logged to the system log.

     To be ``secure'', the referenced file must exist, be a regular file (and not a directory), owned by the super-user, and writable only by the
     super-user.

SEE ALSO

     openlog(3)

HISTORY

     The secure_path() function is based on the BSD/OS implementation of same, and appeared in NetBSD 1.5 by kind permission.

BSD
								    May 4, 2010 							       BSD

ACCESS(2)						      BSD System Calls Manual							 ACCESS(2)

NAME

     access -- check access permissions of a file or pathname

LIBRARY

     Standard C Library (libc, -lc)

SYNOPSIS

     #include <unistd.h>

     int
     access(const char *path, int mode);

DESCRIPTION

     The access() function checks the accessibility of the file named by path for the access permissions indicated by mode.  The value of mode is
     the bitwise inclusive OR of the access permissions to be checked (R_OK for read permission, W_OK for write permission and X_OK for exe-
     cute/search permission) or the existence test, F_OK.  All components of the pathname path are checked for access permissions (including
     F_OK).

     The real user ID is used in place of the effective user ID and the real group access list (including the real group ID) are used in place of
     the effective ID for verifying permission.

     If a process has super-user privileges and indicates success for R_OK or W_OK, the file may not actually have read or write permission bits
     set.  If a process has super-user privileges and indicates success for X_OK, at least one of the user, group, or other execute bits is set.
     (However, the file may still not be executable.  See execve(2).)

RETURN VALUES

     If path cannot be found or if any of the desired access modes would not be granted, then a -1 value is returned; otherwise a 0 value is
     returned.

ERRORS

     Access to the file is denied if:

     [EACCES]		Permission bits of the file mode do not permit the requested access, or search permission is denied on a component of the
			path prefix.  The owner of a file has permission checked with respect to the ``owner'' read, write, and execute mode bits,
			members of the file's group other than the owner have permission checked with respect to the ``group'' mode bits, and all
			others have permissions checked with respect to the ``other'' mode bits.

     [EFAULT]		path points outside the process's allocated address space.

     [EIO]		An I/O error occurred while reading from or writing to the file system.

     [ELOOP]		Too many symbolic links were encountered in translating the pathname.

     [ENAMETOOLONG]	A component of a pathname exceeded {NAME_MAX} characters, or an entire path name exceeded {PATH_MAX} characters.

     [ENOENT]		The named file does not exist.

     [ENOTDIR]		A component of the path prefix is not a directory.

     [EROFS]		Write access is requested for a file on a read-only file system.

     [ETXTBSY]		Write access is requested for a pure procedure (shared text) file presently being executed.

SEE ALSO

     chmod(2), execve(2), stat(2), secure_path(3)

STANDARDS

     The access() function conforms to ISO/IEC 9945-1:1990 (``POSIX.1'').

SECURITY CONSIDERATIONS

     The access() system call is a potential security hole due to race conditions.  It should never be used.  Set-user-ID and set-group-ID appli-
     cations should restore the effective user or group ID, and perform actions directly rather than use access() to simulate access checks for
     the real user or group ID.

     The access() system call may however have some value in providing clues to users as to whether certain operations make sense for a particular
     filesystem object.  Arguably it also allows a cheaper file existence test than stat(2).

BSD
								    May 3, 2010 							       BSD