Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

issetugid(2) [freebsd man page]

ISSETUGID(2)						      BSD System Calls Manual						      ISSETUGID(2)

issetugid -- is current process tainted by uid or gid changes LIBRARY
Standard C Library (libc, -lc) SYNOPSIS
#include <unistd.h> int issetugid(void); DESCRIPTION
The issetugid() system call returns 1 if the process environment or memory address space is considered ``tainted'', and returns 0 otherwise. A process is tainted if it was created as a result of an execve(2) system call which had either of the setuid or setgid bits set (and extra privileges were given as a result) or if it has changed any of its real, effective or saved user or group ID's since it began execution. This system call exists so that library routines (eg: libc, libtermcap) can reliably determine if it is safe to use information that was obtained from the user, in particular the results from getenv(3) should be viewed with suspicion if it is used to control operation. A ``tainted'' status is inherited by child processes as a result of the fork(2) system call (or other library code that calls fork, such as popen(3)). It is assumed that a program that clears all privileges as it prepares to execute another will also reset the environment, hence the ``tainted'' status will not be passed on. This is important for programs such as su(1) which begin setuid but need to be able to create an untainted process. ERRORS
The issetugid() system call is always successful, and no return value is reserved to indicate an error. SEE ALSO
execve(2), fork(2), setegid(2), seteuid(2), setgid(2), setregid(2), setreuid(2), setuid(2) HISTORY
The issetugid() system call first appeared in OpenBSD 2.0 and was also implemented in FreeBSD 3.0. BSD
August 25, 1996 BSD

Check Out this Related Man Page

SETUID(2)						      BSD System Calls Manual							 SETUID(2)

setuid, seteuid, setgid, setegid -- set user and group ID LIBRARY
Standard C Library (libc, -lc) SYNOPSIS
#include <sys/types.h> #include <unistd.h> int setuid(uid_t uid); int seteuid(uid_t euid); int setgid(gid_t gid); int setegid(gid_t egid); DESCRIPTION
The setuid() system call sets the real and effective user IDs and the saved set-user-ID of the current process to the specified value. The setuid() system call is permitted if the specified ID is equal to the real user ID or the effective user ID of the process, or if the effec- tive user ID is that of the super user. The setgid() system call sets the real and effective group IDs and the saved set-group-ID of the current process to the specified value. The setgid() system call is permitted if the specified ID is equal to the real group ID or the effective group ID of the process, or if the effective user ID is that of the super user. The seteuid() system call (setegid()) sets the effective user ID (group ID) of the current process. The effective user ID may be set to the value of the real user ID or the saved set-user-ID (see intro(2) and execve(2)); in this way, the effective user ID of a set-user-ID exe- cutable may be toggled by switching to the real user ID, then re-enabled by reverting to the set-user-ID value. Similarly, the effective group ID may be set to the value of the real group ID or the saved set-group-ID. RETURN VALUES
Upon successful completion, the value 0 is returned; otherwise the value -1 is returned and the global variable errno is set to indicate the error. ERRORS
The system calls will fail if: [EPERM] The user is not the super user and the ID specified is not the real, effective ID, or saved ID. SEE ALSO
getgid(2), getuid(2), issetugid(2), setregid(2), setreuid(2) STANDARDS
The setuid() and setgid() system calls are compliant with the ISO/IEC 9945-1:1990 (``POSIX.1'') specification with _POSIX_SAVED_IDS not defined with the permitted extensions from Appendix B.4.2.2. The seteuid() and setegid() system calls are extensions based on the POSIX con- cept of _POSIX_SAVED_IDS, and have been proposed for a future revision of the standard. HISTORY
The setuid() and setgid() functions appeared in Version 7 AT&T UNIX. SECURITY CONSIDERATIONS
Read and write permissions to files are determined upon a call to open(2). Once a file descriptor is open, dropping privilege does not affect the process's read/write permissions, even if the user ID specified has no read or write permissions to the file. These files nor- mally remain open in any new process executed, resulting in a user being able to read or modify potentially sensitive data. To prevent these files from remaining open after an exec(3) call, be sure to set the close-on-exec flag: void pseudocode(void) { int fd; /* ... */ fd = open("/path/to/sensitive/data", O_RDWR); if (fd == -1) err(1, "open"); /* * Set close-on-exec flag; see fcntl(2) for more information. */ if (fcntl(fd, F_SETFD, FD_CLOEXEC) == -1) err(1, "fcntl(F_SETFD)"); /* ... */ execve(path, argv, environ); } BSD
June 4, 1993 BSD
Man Page

Featured Tech Videos