In /var/log/grsec.log I got plenty of these: Jul 19 10:07:40 ftp grsec: denied resource overstep by requesting 4071424 for RLIMIT_MEMLOCK against limit 32768 for /usr/sbin/ntpd[ntpd:7157] uid/euid:123/123 gid/egid:123/123, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0 Reproducible: Always Steps to Reproduce: 1. compile kernel with grsec support (hardened-sources-2.6.11-r15) and use it 2. run ntpd 2. watch grsec logfile Actual Results: Entries "...grsec: denied resource overstep by requesting 4071424 for RLIMIT_MEMLOCK against limit 32768..." appear every hour after some time Expected Results: ntpd should not produce these entries in grsec logfile ntpd runs with the following options: /usr/sbin/ntpd -p /var/run/ntpd.pid -u ntp:ntp -i /var/chroot/ntp I tried without chroot - result is the same Look at provided URL to get more information about the problem + patch
I get a 404 on that URL. Perhaps you mean <http://lists.ntp.isc.org/pipermail/ hackers/2005-June/001418.html>?
(In reply to comment #1) > I get a 404 on that URL. Perhaps you mean <http://lists.ntp.isc.org/pipermail/ > hackers/2005-June/001418.html>? Here is the copy of the post to ntp:hackers list: [ntp:hackers] [PATCH] - ntpd Exiting:out of memory. Jim Houston jim.houston at comcast.net Wed Jun 15 09:39:34 PDT 2005 * Previous message: [ntp:hackers] Standardizing NTP... * Next message: [ntp:hackers] NTP application status * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] Hi Everyone, When I run ntpd on Linux and use the drop root option I almost always get a "Exiting:out of memory" failure. This is caused by Linux setting a very small default value for RLIMIT_MEMLOCK. On the RH EL3 systems its only 32K bytes. This means that any malloc call after ntpd drops root privlege are likely to fail because the RLIMIT_MEMLOCK limit prevents locking more memory. The attached patch sets both the rl_cur and rl_max values to 32M bytes. To be useful this value has to be larger than the largest ntpd resident set size. I checked ntpd built for an AMD opteron. It was using 19M bytes. Jim Houston - Concurrent Computer Corp. --- ntp-stable-4.2.0a-20040617/ntpd/ntpd.c.0 2005-06-14 12:02:43.000000000 -0400 +++ ntp-stable-4.2.0a-20040617/ntpd/ntpd.c 2005-06-15 12:12:13.253809589 -0400 @@ -691,6 +691,16 @@ "Cannot adjust stack limit for mlockall: %m"); } } + /* + * The default RLIMIT_MEMLOCK is very low on Linux systems. + * Unless we increase this limit malloc calls are likely to + * fail if we drop root privlege. To be useful the value + * has to be larger than the largest ntpd resident set size. + */ + rl.rlim_cur = rl.rlim_max = 32*1024*1024; + if (setrlimit(RLIMIT_MEMLOCK, &rl) == -1) { + msyslog(LOG_ERR, "Cannot set RLIMIT_MEMLOCK: %m"); + } } # endif /* HAVE_SETRLIMIT */ /*
I've now been running this patch for a day, and it seems to solve the problem for me. However, 32MB seems excessive - my ntpd process is only 7MB, so I set the limit to 10MB. My local NTP master server is very short on physical memory, and a runaway ntpd that locked the full 32MB would not be good.
(In reply to comment #3) > I've now been running this patch for a day, and it seems to solve the problem > for me. However, 32MB seems excessive - my ntpd process is only 7MB, so I set > the limit to 10MB. My local NTP master server is very short on physical memory, > and a runaway ntpd that locked the full 32MB would not be good. I don't think it will lock the whole 32MB. We only set maximum allowed size to 32MB however process will lock only the amount it actually uses. Extracted from mlockall manual page: mlockall() locks all of the calling process's virtual address space into RAM, preventing that memory from being paged to the swap area. This means that we should set RLIMIT_MEMLOCK to something above the highest possible value and amount of locked memory will depend on how much virtual memory process actually consumes. On my i686 (-Os) ntpd consumes ~4MB and on athlon64 (-O3) ntpd consumes ~16MB.
Created attachment 65963 [details, diff] added rlimit-memlock.patch
Created attachment 65964 [details, diff] patch to increase the memory lock limit the patch posted from Marcin Deranekl
Added the patch as attachement and adjusted the ebuild from stable accordingly. Could anybody test and confirm if it works? Thanks.
this really needs to go through upstream ntp first https://ntp.isc.org/bugs/
posted on ntp.isc.org: https://ntp.isc.org/bugs/show_bug.cgi?id=477 Will report back if upstream has accepted it. @vapier: Shouldn't this get patched in portage until upstream releases a new release?
Okay, that was fast. It's fixed in the ntp cvs, and will be in the 4.2.1 release. (see https://ntp.isc.org/bugs/show_bug.cgi?id=477) Could we fix it with the patch from #6 until 4.2.1 is out?
added to ntp-4.2.0.20050303, thanks for doing all the hard work :)
*** Bug 117910 has been marked as a duplicate of this bug. ***
Looks like this has re-entered upstream, anyone care to re-open there (so I don't need to open another bugzilla account)? Thanks,
Ugh, sorry, misread some versions, has nothing to do with upstream, this is just about the bug occuring in an earlier version, 20050303 is still in ~arch. Looks like patch for it works with 20040617-r3 though, so should be a quick fix, or 20050303 could be marked stable.
file a new bug for ntp stabilization
