* [PATCH 2.6.27-rc5] Allow set RLIMIT_NOFILE to RLIM_INFINITY
@ 2008-09-09 7:14 Adam Tkac
2008-09-10 21:31 ` Andrew Morton
0 siblings, 1 reply; 7+ messages in thread
From: Adam Tkac @ 2008-09-09 7:14 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 266 bytes --]
Hi all,
when process wants set limit of open files to RLIM_INFINITY it gets
EPERM even if it has CAP_SYS_RESOURCE capability. Attached patch
should fix the problem. Please add me to CC of your responses because
I'm not member of list.
Regards, Adam
--
Adam Tkac
[-- Attachment #2: linux26-openfiles.patch --]
[-- Type: text/plain, Size: 633 bytes --]
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1458,8 +1458,14 @@ asmlinkage long sys_setrlimit(unsigned i
if ((new_rlim.rlim_max > old_rlim->rlim_max) &&
!capable(CAP_SYS_RESOURCE))
return -EPERM;
- if (resource == RLIMIT_NOFILE && new_rlim.rlim_max > sysctl_nr_open)
- return -EPERM;
+ if (resource == RLIMIT_NOFILE) {
+ if (new_rlim.rlim_max == RLIM_INFINITY)
+ new_rlim.rlim_max = sysctl_nr_open;
+ if (new_rlim.rlim_cur == RLIM_INFINITY)
+ new_rlim.rlim_cur = sysctl_nr_open;
+ if (new_rlim.rlim_max > sysctl_nr_open)
+ return -EPERM;
+ }
retval = security_task_setrlimit(resource, &new_rlim);
if (retval)
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 2.6.27-rc5] Allow set RLIMIT_NOFILE to RLIM_INFINITY
2008-09-09 7:14 [PATCH 2.6.27-rc5] Allow set RLIMIT_NOFILE to RLIM_INFINITY Adam Tkac
@ 2008-09-10 21:31 ` Andrew Morton
2008-09-11 7:54 ` Adam Tkac
0 siblings, 1 reply; 7+ messages in thread
From: Andrew Morton @ 2008-09-10 21:31 UTC (permalink / raw)
To: Adam Tkac; +Cc: linux-kernel
On Tue, 9 Sep 2008 09:14:07 +0200
Adam Tkac <vonsch@gmail.com> wrote:
> when process wants set limit of open files to RLIM_INFINITY it gets
> EPERM even if it has CAP_SYS_RESOURCE capability. Attached patch
> should fix the problem. Please add me to CC of your responses because
> I'm not member of list.
>
> Regards, Adam
>
> --
> Adam Tkac
>
>
> [linux26-openfiles.patch text/plain (634B)]
> --- a/kernel/sys.c
> +++ b/kernel/sys.c
> @@ -1458,8 +1458,14 @@ asmlinkage long sys_setrlimit(unsigned i
> if ((new_rlim.rlim_max > old_rlim->rlim_max) &&
> !capable(CAP_SYS_RESOURCE))
> return -EPERM;
> - if (resource == RLIMIT_NOFILE && new_rlim.rlim_max > sysctl_nr_open)
> - return -EPERM;
> + if (resource == RLIMIT_NOFILE) {
> + if (new_rlim.rlim_max == RLIM_INFINITY)
> + new_rlim.rlim_max = sysctl_nr_open;
> + if (new_rlim.rlim_cur == RLIM_INFINITY)
> + new_rlim.rlim_cur = sysctl_nr_open;
> + if (new_rlim.rlim_max > sysctl_nr_open)
> + return -EPERM;
> + }
The kernel has had this behaviour for a long time. 2.6.13 had:
if ((new_rlim.rlim_max > old_rlim->rlim_max) &&
!capable(CAP_SYS_RESOURCE))
return -EPERM;
if (resource == RLIMIT_NOFILE && new_rlim.rlim_max > NR_OPEN)
return -EPERM;
I don't immediately see a problem with your change, but what makes you
believe that it is needed? Is there some standard which we're
violating? Is there some operational situation in which the current
behaviour is causing a problem?
Thanks.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 2.6.27-rc5] Allow set RLIMIT_NOFILE to RLIM_INFINITY
2008-09-10 21:31 ` Andrew Morton
@ 2008-09-11 7:54 ` Adam Tkac
2008-09-11 19:22 ` Andrew Morton
0 siblings, 1 reply; 7+ messages in thread
From: Adam Tkac @ 2008-09-11 7:54 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Wed, Sep 10, 2008 at 02:31:41PM -0700, Andrew Morton wrote:
> On Tue, 9 Sep 2008 09:14:07 +0200
> Adam Tkac <vonsch@gmail.com> wrote:
>
> > when process wants set limit of open files to RLIM_INFINITY it gets
> > EPERM even if it has CAP_SYS_RESOURCE capability. Attached patch
> > should fix the problem. Please add me to CC of your responses because
> > I'm not member of list.
> >
> > Regards, Adam
> >
> > --
> > Adam Tkac
> >
> >
> > [linux26-openfiles.patch text/plain (634B)]
> > --- a/kernel/sys.c
> > +++ b/kernel/sys.c
> > @@ -1458,8 +1458,14 @@ asmlinkage long sys_setrlimit(unsigned i
> > if ((new_rlim.rlim_max > old_rlim->rlim_max) &&
> > !capable(CAP_SYS_RESOURCE))
> > return -EPERM;
> > - if (resource == RLIMIT_NOFILE && new_rlim.rlim_max > sysctl_nr_open)
> > - return -EPERM;
> > + if (resource == RLIMIT_NOFILE) {
> > + if (new_rlim.rlim_max == RLIM_INFINITY)
> > + new_rlim.rlim_max = sysctl_nr_open;
> > + if (new_rlim.rlim_cur == RLIM_INFINITY)
> > + new_rlim.rlim_cur = sysctl_nr_open;
> > + if (new_rlim.rlim_max > sysctl_nr_open)
> > + return -EPERM;
> > + }
>
> The kernel has had this behaviour for a long time. 2.6.13 had:
>
> if ((new_rlim.rlim_max > old_rlim->rlim_max) &&
> !capable(CAP_SYS_RESOURCE))
> return -EPERM;
> if (resource == RLIMIT_NOFILE && new_rlim.rlim_max > NR_OPEN)
> return -EPERM;
>
> I don't immediately see a problem with your change, but what makes you
> believe that it is needed? Is there some standard which we're
> violating? Is there some operational situation in which the current
> behaviour is causing a problem?
>
> Thanks.
Well, this change is not _absolutely_ needed because everyone who wants
unlimited file descriptors he could set it to NR_OPEN. Look on
example (from BIND):
...
#elif defined(NR_OPEN) && defined(__linux__)
/*
* Some Linux kernels don't accept RLIM_INFINIT; the maximum
* possible value is the NR_OPEN defined in linux/fs.h.
*/
if (resource == isc_resource_openfiles && rlim_value == RLIM_INFINITY) {
rl.rlim_cur = rl.rlim_max = NR_OPEN;
unixresult = setrlimit(unixresource, &rl);
if (unixresult == 0)
return (ISC_R_SUCCESS);
}
#elif ...
I think that when you allow set RLIMIT_NOFILE to RLIM_INFINITY you
increase portability - you don't have to check if OS is linux and then
use different schema for limits.
Regards, Adam
--
Adam Tkac
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 2.6.27-rc5] Allow set RLIMIT_NOFILE to RLIM_INFINITY
2008-09-11 7:54 ` Adam Tkac
@ 2008-09-11 19:22 ` Andrew Morton
2008-09-12 11:06 ` Adam Tkac
0 siblings, 1 reply; 7+ messages in thread
From: Andrew Morton @ 2008-09-11 19:22 UTC (permalink / raw)
To: Adam Tkac; +Cc: linux-kernel
On Thu, 11 Sep 2008 09:54:38 +0200
Adam Tkac <vonsch@gmail.com> wrote:
> On Wed, Sep 10, 2008 at 02:31:41PM -0700, Andrew Morton wrote:
> > On Tue, 9 Sep 2008 09:14:07 +0200
> > Adam Tkac <vonsch@gmail.com> wrote:
> >
> > > when process wants set limit of open files to RLIM_INFINITY it gets
> > > EPERM even if it has CAP_SYS_RESOURCE capability. Attached patch
> > > should fix the problem. Please add me to CC of your responses because
> > > I'm not member of list.
> > >
> > > Regards, Adam
> > >
> > > --
> > > Adam Tkac
> > >
> > >
> > > [linux26-openfiles.patch text/plain (634B)]
> > > --- a/kernel/sys.c
> > > +++ b/kernel/sys.c
> > > @@ -1458,8 +1458,14 @@ asmlinkage long sys_setrlimit(unsigned i
> > > if ((new_rlim.rlim_max > old_rlim->rlim_max) &&
> > > !capable(CAP_SYS_RESOURCE))
> > > return -EPERM;
> > > - if (resource == RLIMIT_NOFILE && new_rlim.rlim_max > sysctl_nr_open)
> > > - return -EPERM;
> > > + if (resource == RLIMIT_NOFILE) {
> > > + if (new_rlim.rlim_max == RLIM_INFINITY)
> > > + new_rlim.rlim_max = sysctl_nr_open;
> > > + if (new_rlim.rlim_cur == RLIM_INFINITY)
> > > + new_rlim.rlim_cur = sysctl_nr_open;
> > > + if (new_rlim.rlim_max > sysctl_nr_open)
> > > + return -EPERM;
> > > + }
> >
> > The kernel has had this behaviour for a long time. 2.6.13 had:
> >
> > if ((new_rlim.rlim_max > old_rlim->rlim_max) &&
> > !capable(CAP_SYS_RESOURCE))
> > return -EPERM;
> > if (resource == RLIMIT_NOFILE && new_rlim.rlim_max > NR_OPEN)
> > return -EPERM;
> >
> > I don't immediately see a problem with your change, but what makes you
> > believe that it is needed? Is there some standard which we're
> > violating? Is there some operational situation in which the current
> > behaviour is causing a problem?
> >
> > Thanks.
>
> Well, this change is not _absolutely_ needed because everyone who wants
> unlimited file descriptors he could set it to NR_OPEN. Look on
> example (from BIND):
>
> ...
> #elif defined(NR_OPEN) && defined(__linux__)
> /*
> * Some Linux kernels don't accept RLIM_INFINIT; the maximum
> * possible value is the NR_OPEN defined in linux/fs.h.
> */
> if (resource == isc_resource_openfiles && rlim_value == RLIM_INFINITY) {
> rl.rlim_cur = rl.rlim_max = NR_OPEN;
> unixresult = setrlimit(unixresource, &rl);
> if (unixresult == 0)
> return (ISC_R_SUCCESS);
> }
> #elif ...
>
> I think that when you allow set RLIMIT_NOFILE to RLIM_INFINITY you
> increase portability - you don't have to check if OS is linux and then
> use different schema for limits.
>
OK.
I updated the changelog as below.
Please send a Signed-off-by: for thsi change, as per section 12 of
Documentation/SubmittingPatches.
Thanks.
From: Adam Tkac <vonsch@gmail.com>
When a process wants to set the limit of open files to RLIM_INFINITY it
gets EPERM even if it has CAP_SYS_RESOURCE capability.
For example, BIND does:
...
#elif defined(NR_OPEN) && defined(__linux__)
/*
* Some Linux kernels don't accept RLIM_INFINIT; the maximum
* possible value is the NR_OPEN defined in linux/fs.h.
*/
if (resource == isc_resource_openfiles && rlim_value == RLIM_INFINITY) {
rl.rlim_cur = rl.rlim_max = NR_OPEN;
unixresult = setrlimit(unixresource, &rl);
if (unixresult == 0)
return (ISC_R_SUCCESS);
}
#elif ...
If we allow setting RLIMIT_NOFILE to RLIM_INFINITY we increase portability
- you don't have to check if OS is linux and then use different schema for
limits.
The spec says "Specifying RLIM_INFINITY as any resource limit value on a
successful call to setrlimit() shall inhibit enforcement of that resource
limit." and we're presently not doing that.
Cc: Michael Kerrisk <mtk.manpages@googlemail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
kernel/sys.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff -puN kernel/sys.c~rlimit-permit-setting-rlimit_nofile-to-rlim_infinity kernel/sys.c
--- a/kernel/sys.c~rlimit-permit-setting-rlimit_nofile-to-rlim_infinity
+++ a/kernel/sys.c
@@ -1532,8 +1532,14 @@ asmlinkage long sys_setrlimit(unsigned i
if ((new_rlim.rlim_max > old_rlim->rlim_max) &&
!capable(CAP_SYS_RESOURCE))
return -EPERM;
- if (resource == RLIMIT_NOFILE && new_rlim.rlim_max > sysctl_nr_open)
- return -EPERM;
+ if (resource == RLIMIT_NOFILE) {
+ if (new_rlim.rlim_max == RLIM_INFINITY)
+ new_rlim.rlim_max = sysctl_nr_open;
+ if (new_rlim.rlim_cur == RLIM_INFINITY)
+ new_rlim.rlim_cur = sysctl_nr_open;
+ if (new_rlim.rlim_max > sysctl_nr_open)
+ return -EPERM;
+ }
retval = security_task_setrlimit(resource, &new_rlim);
if (retval)
_
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH 2.6.27-rc5] Allow set RLIMIT_NOFILE to RLIM_INFINITY
2008-09-11 19:22 ` Andrew Morton
@ 2008-09-12 11:06 ` Adam Tkac
2008-09-12 11:20 ` Andreas Schwab
0 siblings, 1 reply; 7+ messages in thread
From: Adam Tkac @ 2008-09-12 11:06 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel, akpm, mtk.manpages
When a process wants to set the limit of open files to RLIM_INFINITY it
gets EPERM even if it has CAP_SYS_RESOURCE capability.
For example, BIND does:
...
#elif defined(NR_OPEN) && defined(__linux__)
/*
* Some Linux kernels don't accept RLIM_INFINIT; the maximum
* possible value is the NR_OPEN defined in linux/fs.h.
*/
if (resource == isc_resource_openfiles && rlim_value == RLIM_INFINITY) {
rl.rlim_cur = rl.rlim_max = NR_OPEN;
unixresult = setrlimit(unixresource, &rl);
if (unixresult == 0)
return (ISC_R_SUCCESS);
}
#elif ...
If we allow setting RLIMIT_NOFILE to RLIM_INFINITY we increase portability
- you don't have to check if OS is linux and then use different schema for
limits.
The spec says "Specifying RLIM_INFINITY as any resource limit value on a
successful call to setrlimit() shall inhibit enforcement of that resource
limit." and we're presently not doing that.
Cc: Michael Kerrisk <mtk.manpages@googlemail.com>
Signed-off-by: Adam Tkac <vonsch@gmail.com>
Tested-by: Adam Tkac <vonsch@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
kernel/sys.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff -puN kernel/sys.c~rlimit-permit-setting-rlimit_nofile-to-rlim_infinity kernel/sys.c
--- a/kernel/sys.c~rlimit-permit-setting-rlimit_nofile-to-rlim_infinity
+++ a/kernel/sys.c
@@ -1532,8 +1532,14 @@ asmlinkage long sys_setrlimit(unsigned i
if ((new_rlim.rlim_max > old_rlim->rlim_max) &&
!capable(CAP_SYS_RESOURCE))
return -EPERM;
- if (resource == RLIMIT_NOFILE && new_rlim.rlim_max > sysctl_nr_open)
- return -EPERM;
+ if (resource == RLIMIT_NOFILE) {
+ if (new_rlim.rlim_max == RLIM_INFINITY)
+ new_rlim.rlim_max = sysctl_nr_open;
+ if (new_rlim.rlim_cur == RLIM_INFINITY)
+ new_rlim.rlim_cur = sysctl_nr_open;
+ if (new_rlim.rlim_max > sysctl_nr_open)
+ return -EPERM;
+ }
retval = security_task_setrlimit(resource, &new_rlim);
if (retval)
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 2.6.27-rc5] Allow set RLIMIT_NOFILE to RLIM_INFINITY
2008-09-12 11:06 ` Adam Tkac
@ 2008-09-12 11:20 ` Andreas Schwab
2008-09-12 11:52 ` Adam Tkac
0 siblings, 1 reply; 7+ messages in thread
From: Andreas Schwab @ 2008-09-12 11:20 UTC (permalink / raw)
To: Adam Tkac; +Cc: torvalds, linux-kernel, akpm, mtk.manpages
Adam Tkac <vonsch@gmail.com> writes:
> diff -puN kernel/sys.c~rlimit-permit-setting-rlimit_nofile-to-rlim_infinity kernel/sys.c
> --- a/kernel/sys.c~rlimit-permit-setting-rlimit_nofile-to-rlim_infinity
> +++ a/kernel/sys.c
> @@ -1532,8 +1532,14 @@ asmlinkage long sys_setrlimit(unsigned i
> if ((new_rlim.rlim_max > old_rlim->rlim_max) &&
> !capable(CAP_SYS_RESOURCE))
> return -EPERM;
> - if (resource == RLIMIT_NOFILE && new_rlim.rlim_max > sysctl_nr_open)
> - return -EPERM;
> + if (resource == RLIMIT_NOFILE) {
> + if (new_rlim.rlim_max == RLIM_INFINITY)
> + new_rlim.rlim_max = sysctl_nr_open;
> + if (new_rlim.rlim_cur == RLIM_INFINITY)
> + new_rlim.rlim_cur = sysctl_nr_open;
> + if (new_rlim.rlim_max > sysctl_nr_open)
> + return -EPERM;
This makes it possible to set cur > nr_open (when max = INF but nr_open
< cur < INF). You need to check that cur <= max after adjustment.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 2.6.27-rc5] Allow set RLIMIT_NOFILE to RLIM_INFINITY
2008-09-12 11:20 ` Andreas Schwab
@ 2008-09-12 11:52 ` Adam Tkac
0 siblings, 0 replies; 7+ messages in thread
From: Adam Tkac @ 2008-09-12 11:52 UTC (permalink / raw)
To: Andreas Schwab; +Cc: torvalds, linux-kernel, akpm, mtk.manpages
[-- Attachment #1: Type: text/plain, Size: 1224 bytes --]
On Fri, Sep 12, 2008 at 01:20:46PM +0200, Andreas Schwab wrote:
> Adam Tkac <vonsch@gmail.com> writes:
>
> > diff -puN kernel/sys.c~rlimit-permit-setting-rlimit_nofile-to-rlim_infinity kernel/sys.c
> > --- a/kernel/sys.c~rlimit-permit-setting-rlimit_nofile-to-rlim_infinity
> > +++ a/kernel/sys.c
> > @@ -1532,8 +1532,14 @@ asmlinkage long sys_setrlimit(unsigned i
> > if ((new_rlim.rlim_max > old_rlim->rlim_max) &&
> > !capable(CAP_SYS_RESOURCE))
> > return -EPERM;
> > - if (resource == RLIMIT_NOFILE && new_rlim.rlim_max > sysctl_nr_open)
> > - return -EPERM;
> > + if (resource == RLIMIT_NOFILE) {
> > + if (new_rlim.rlim_max == RLIM_INFINITY)
> > + new_rlim.rlim_max = sysctl_nr_open;
> > + if (new_rlim.rlim_cur == RLIM_INFINITY)
> > + new_rlim.rlim_cur = sysctl_nr_open;
> > + if (new_rlim.rlim_max > sysctl_nr_open)
> > + return -EPERM;
>
> This makes it possible to set cur > nr_open (when max = INF but nr_open
> < cur < INF). You need to check that cur <= max after adjustment.
>
> Andreas.
>
Right you are. Improved patch is attached, when cur > max && cur !=
INF after adjustment EINVAL is returned. (cur can be also set to max
but it seems like bad solution for me)
--
Adam Tkac
[-- Attachment #2: linux26-openfiles.patch --]
[-- Type: text/plain, Size: 1967 bytes --]
When a process wants to set the limit of open files to RLIM_INFINITY it
gets EPERM even if it has CAP_SYS_RESOURCE capability.
For example, BIND does:
...
#elif defined(NR_OPEN) && defined(__linux__)
/*
* Some Linux kernels don't accept RLIM_INFINIT; the maximum
* possible value is the NR_OPEN defined in linux/fs.h.
*/
if (resource == isc_resource_openfiles && rlim_value == RLIM_INFINITY) {
rl.rlim_cur = rl.rlim_max = NR_OPEN;
unixresult = setrlimit(unixresource, &rl);
if (unixresult == 0)
return (ISC_R_SUCCESS);
}
#elif ...
If we allow setting RLIMIT_NOFILE to RLIM_INFINITY we increase portability
- you don't have to check if OS is linux and then use different schema for
limits.
The spec says "Specifying RLIM_INFINITY as any resource limit value on a
successful call to setrlimit() shall inhibit enforcement of that resource
limit." and we're presently not doing that.
Signed-off-by: Adam Tkac <vonsch@gmail.com>
--- a/kernel/sys.c.openfiles
+++ a/kernel/sys.c
@@ -1469,14 +1469,22 @@ asmlinkage long sys_setrlimit(unsigned i
return -EINVAL;
if (copy_from_user(&new_rlim, rlim, sizeof(*rlim)))
return -EFAULT;
- if (new_rlim.rlim_cur > new_rlim.rlim_max)
- return -EINVAL;
old_rlim = current->signal->rlim + resource;
if ((new_rlim.rlim_max > old_rlim->rlim_max) &&
!capable(CAP_SYS_RESOURCE))
return -EPERM;
- if (resource == RLIMIT_NOFILE && new_rlim.rlim_max > sysctl_nr_open)
- return -EPERM;
+
+ if (resource == RLIMIT_NOFILE) {
+ if (new_rlim.rlim_max == RLIM_INFINITY)
+ new_rlim.rlim_max = sysctl_nr_open;
+ if (new_rlim.rlim_cur == RLIM_INFINITY)
+ new_rlim.rlim_cur = sysctl_nr_open;
+ if (new_rlim.rlim_max > sysctl_nr_open)
+ return -EPERM;
+ }
+
+ if (new_rlim.rlim_cur > new_rlim.rlim_max)
+ return -EINVAL;
retval = security_task_setrlimit(resource, &new_rlim);
if (retval)
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2008-09-12 11:52 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-09-09 7:14 [PATCH 2.6.27-rc5] Allow set RLIMIT_NOFILE to RLIM_INFINITY Adam Tkac
2008-09-10 21:31 ` Andrew Morton
2008-09-11 7:54 ` Adam Tkac
2008-09-11 19:22 ` Andrew Morton
2008-09-12 11:06 ` Adam Tkac
2008-09-12 11:20 ` Andreas Schwab
2008-09-12 11:52 ` Adam Tkac
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox