DESCRIPTION
The suser and suser_cred functions check if the credentials given include superuser powers. The suser function is the most common, and should be used unless special circumstances dictate otherwise.
The suser_cred function should be used when the credentials to be checked are not the thread’s own, when there is no thread, when superuser powers should be extended to imprisoned roots, or when the credential to be checked is the real user rather than the effective user.
By default, a process does not command superuser powers if it has been imprisoned by the jail(2) system call. There are cases however where this is appropriate, and this can be done by passing SUSER_ALLOWJAIL in the flag argument to the suser_cred function. It is important to review carefully in each case that this does not weaken the prison. Generally, only where the action is protected by chroot(2) implicit in the jail(2) call should such powers be granted.
By default, the credential checked is the effective user. There are cases where it is instead necessary to check the real user (for example, when determining if resource limits should be applied), and this can be done by passing the SUSER_RUID flag in the flag argument to the suser_cred function.
The suser and suser_cred functions note the fact that superuser powers have been used in the process structure of the process specified. Because part of their function is to notice whether superuser powers have been used, the functions should only be called after other permission possibilities have been exhausted.
RETURN VALUES
The suser and suser_cred functions return 0 if the user has superuser powers and EPERM otherwise. This is the reverse logic of some other implementations of suser in which a TRUE response indicates superuser powers.
SEE ALSO
chroot(2), jail(2)
BUGS
