Fwd: Bug#765410: ulimit broken as root if it fails once [origin: goswin-v-b@web.de]

Fwd: Bug#765410: ulimit broken as root if it fails once [origin: goswin-v-b@web.de]

[Axel Beckert]

Hi,

the following has been reported in Debian at
http://bugs.debian.org/765410 and I can reprodcue it with 4.3.10,
4.3.17, 5.0.6 and 5.0.7.

The issue seems to only appear if ulimit is run as root user. I was
not able to reproduce it as non-root user. (I was also unable to
reproduce it on any of Debian's kfreebsd-* architectures, so it may be
a linux-only issue, too.)

----- Forwarded message from Goswin von Brederlow <goswin-v-b@web.de> -----
Date: Tue, 14 Oct 2014 21:42:26 +0200
From: Goswin von Brederlow <goswin-v-b@web.de>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: [Pkg-zsh-devel] Bug#765410: ulimit broken if it fails once
Reply-To: Goswin von Brederlow <goswin-v-b@web.de>, 765410@bugs.debian.org

Package: zsh
Version: 5.0.5-2
Severity: normal

root@frosties:~# ulimit -n 1000   
root@frosties:~# ulimit -n 10000000
limit: setrlimit failed: operation not permitted
root@frosties:~# ulimit -n 1000   
limit: setrlimit failed: operation not permitted

Once setting a limit with ulimit fails all further attempts to set a
limit will also fail. But only in zsh. Works fine in bash.

MfG
	Goswin

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages zsh depends on:
ii  libc6       2.19-1
ii  libcap2     1:2.22-1.2
ii  libtinfo5   5.9+20140913-1
ii  zsh-common  5.0.5-2

Versions of packages zsh recommends:
ii  libncursesw5  5.9+20140913-1
ii  libpcre3      1:8.31-5

Versions of packages zsh suggests:
pn  zsh-doc  <none>

-- debconf information excluded
----- End forwarded message -----

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe@deuxchevaux.org  (Mail)
 X   See http://www.nonhtmlmail.org/campaign.html | abe@noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Re: Fwd: Bug#765410: ulimit broken as root if it fails once [origin: goswin-v-b@web.de]

[Bart Schaefer]

On Oct 16, 12:33am, Axel Beckert wrote:
}
} the following has been reported in Debian at
} http://bugs.debian.org/765410 and I can reprodcue it with 4.3.10,
} 4.3.17, 5.0.6 and 5.0.7.
} 
} The issue seems to only appear if ulimit is run as root user. I was
} not able to reproduce it as non-root user. (I was also unable to
} reproduce it on any of Debian's kfreebsd-* architectures, so it may be
} a linux-only issue, too.)

This is primarily a documentation issue.

As root, "ulimit" by default attempts to raise both the hard and soft
limits, but only lowers the soft ones.  Each time you try to lower the
soft limit, it attempts to re-assert the previously specified hard limit,
and generates the error -- but the soft limit is in fact been correctly
changed, as you can see by examining the output of the "limit" command
(without the leading "u").

To lower the hard limit again and make the error message go away, one
simply has to use "ulimit -H ...".

This could also be fixed by having bin_ulimit read back the actual limit
after a failure to set the hard limit and store that instead of keeping
the "desired" hard limit around and trying to change it again.

Re: Bug#765410: ulimit broken as root if it fails once [origin: goswin-v-b@web.de]

[Peter Stephenson]

On Wed, 15 Oct 2014 19:49:13 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> This could also be fixed by having bin_ulimit read back the actual limit
> after a failure to set the hard limit and store that instead of keeping
> the "desired" hard limit around and trying to change it again.

I think that would be preferable --- I noted after the last ulimit query
(zsh-workers/33363, about a different implementation oddity) that this
looked potentially confusing.

pws

Re: Bug#765410: ulimit broken as root if it fails once [origin: goswin-v-b@web.de]

[Bart Schaefer]

On Oct 16,  9:22am, Peter Stephenson wrote:
} Subject: Re: Bug#765410: ulimit broken as root if it fails once [origin: g
}
} On Wed, 15 Oct 2014 19:49:13 -0700
} Bart Schaefer <schaefer@brasslantern.com> wrote:
} > This could also be fixed by having bin_ulimit read back the actual limit
} > after a failure to set the hard limit and store that instead of keeping
} > the "desired" hard limit around and trying to change it again.
} 
} I think that would be preferable --- I noted after the last ulimit query
} (zsh-workers/33363, about a different implementation oddity) that this
} looked potentially confusing.

Patch below fixes the command name in the warning message as well.

diff --git a/Src/Builtins/rlimits.c b/Src/Builtins/rlimits.c
index 9da3183..85ec181 100644
--- a/Src/Builtins/rlimits.c
+++ b/Src/Builtins/rlimits.c
@@ -518,7 +518,7 @@ do_limit(char *nam, int lim, rlim_t val, int hard, int soft, int set)
 		}
 	    } else
 		limits[lim].rlim_cur = val;
-	    if (set && zsetlimit(lim, "limit"))
+	    if (set && zsetlimit(lim, nam))
 		return 1;
 	}
     }
diff --git a/Src/exec.c b/Src/exec.c
index d0fadd6..2f896d8 100644
--- a/Src/exec.c
+++ b/Src/exec.c
@@ -250,6 +250,7 @@ zsetlimit(int limnum, char *nam)
 	if (setrlimit(limnum, limits + limnum)) {
 	    if (nam)
 		zwarnnam(nam, "setrlimit failed: %e", errno);
+	    limits[limnum] = current_limits[limnum];
 	    return -1;
 	}
 	current_limits[limnum] = limits[limnum];