Re: setrlimit(2) is this a defect?

Khimenko Victor (khim@sch57.msk.ru)
Tue, 14 Sep 1999 19:50:39 +0400 (MSD)


In <199909141448.QAA08725@nlsvr1.sybase.com> wtenhave@sybase.com (wtenhave@sybase.com) wrote:
> Hi,

> I think that the setrlimit(2) programmers interface allows incorrect
> unchecked RLIMIT_NOFILE settings when root under glibc-2.1.1-6.
> glibc-2.0.7-29 (RH5.2 showed fine).

> I.e, I do not think that the issue is concerning the kernel but in
> the glibc run-time environment. Since setrlimit(2) is documented
> as a system call I post here. I feel sorry if this is off topic.

> example:

> #include <sys/time.h>
> #include <sys/resource.h>
> #include <unistd.h>

> #define MAX_FD 10000
> #define MIN_FD 256

> main () {
> char s_err[128];
> struct rlimit n_limit;

> if (getrlimit(RLIMIT_NOFILE, &n_limit) < 0) {
> perror ("getrlimit RLIMIT_NOFILE");
> }

> printf ("RLIMIT_NOFILE, rlim_cur = %d, rlim_max %d\n",
> n_limit.rlim_cur, n_limit.rlim_max);

> n_limit.rlim_cur = MAX_FD;
> n_limit.rlim_max = MAX_FD;
> sprintf (s_err, "setrlimit RLIMIT_NOFILE = %d", MAX_FD);

> if (setrlimit (RLIMIT_NOFILE, &n_limit) < 0) {
> perror (s_err);

> n_limit.rlim_cur = MIN_FD;
> n_limit.rlim_max = MIN_FD;
> sprintf (s_err, "setrlimit RLIMIT_NOFILE = %d", MIN_FD);

> if (setrlimit (RLIMIT_NOFILE, &n_limit) < 0) {
> perror (s_err);
> }
> }

> if (getrlimit(RLIMIT_NOFILE, &n_limit) < 0) {
> perror ("getrlimit RLIMIT_NOFILE");
> }

> printf ("RLIMIT_NOFILE, rlim_cur = %d, rlim_max %d\n",
> n_limit.rlim_cur, n_limit.rlim_max);
> }

> Compiling/executing this under various run-time environments shows

> Compiled RH5.2 (glibc-2.0.7-29)
> Executed - none root RH5.2 (glibc-2.0.7-29)
> RLIMIT_NOFILE, rlim_cur = 1024, rlim_max 1024
> setrlimit RLIMIT_NOFILE = 10000: Operation not permitted
> RLIMIT_NOFILE, rlim_cur = 256, rlim_max 256

> Executed - none root RH6.0 (glibc-2.1.1-6)
> RLIMIT_NOFILE, rlim_cur = 1024, rlim_max 1024
> setrlimit RLIMIT_NOFILE = 10000: Operation not permitted
> RLIMIT_NOFILE, rlim_cur = 256, rlim_max 256

> Executed - *root* RH5.2 (glibc-2.0.7-29)
> RLIMIT_NOFILE, rlim_cur = 1024, rlim_max 1024
> setrlimit RLIMIT_NOFILE = 10000: Operation not permitted
> RLIMIT_NOFILE, rlim_cur = 256, rlim_max 256

> Executed - *root* RH6.0 (glibc-2.1.1-6)
> RLIMIT_NOFILE, rlim_cur = 1024, rlim_max 1024
> ********== RLIMIT_NOFILE, rlim_cur = 10000, rlim_max 10000
> *
> * Compiled RH6.0 (glibc-2.1.1-6)
> * Executed - none root RH6.0 (glibc-2.1.1-6)
> * RLIMIT_NOFILE, rlim_cur = 1024, rlim_max 1024
> * setrlimit RLIMIT_NOFILE = 10000: Operation not permitted
> * RLIMIT_NOFILE, rlim_cur = 256, rlim_max 256
> *
> * Executed - *root* RH6.0 (glibc-2.1.1-6)
> * RLIMIT_NOFILE, rlim_cur = 1024, rlim_max 1024
> ********== RLIMIT_NOFILE, rlim_cur = 10000, rlim_max 10000
> *
***>>> EPERM A non-superuser tries to use setrlimit() to
> increase the soft or hard limit above the current
> hard limit, or a superuser tries to increase
> RLIMIT_NOFILE above the current kernel maximum.

> Or do we really allow for 10000 file-descriptors as set in my example?

Yes, this is exactly the case: you can use 10000 file-descriptors per
process (at least in 2.2.XacY series of kernels)...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/