The special value "user" means preserve the invoking user's limit.
The value "default" means don't override the default limit for the
user as assigned by the system (PAM, loging.conf, userdb, etc).
Currently only used for RLIMIT_DATA and RLIMIT_AS.
This works around a problem on HP-UX where setting RLIMIT_DATA
changes the resource limits for both 32-bit and 64-bit processes.
HP-UX processes start out with RLIMIT_DATA set based on the values
of the maxdsiz and maxdsiz_64bit kernel tunables, depending on
whether they are 32-bit or 64-bit. By default this limit is 1GB
for 32-bit processes and 4GB for 64-bit. However, once RLIMIT_DATA
is changed, it does not appear to be possible to restore the old
values. This can result in a 64-bit process that is executed by a
32-bit shell getting the 32-bit RLIMIT_DATA instead of the 64-bit
one. Bug #973
Previously we needed to include headers required by the various
sudo*h files. Now those files are more self-sufficient and we
should only include headers needed by code in the various .c files.
Linux containers don't allow RLIMIT_CORE to be set back to RLIM_INFINITY
if we set the limit to zero, even for root. This is not a problem
outside the container.
EINVAL. On NetBSD, setrlimit(2) can return EINVAL if the new soft
limit is lower than the current resource usage. This can be a
problem when restoring the old stack limit if sudo has raised it.
