Bugzilla Bug 99713

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 an attachment (id=65963) [edit]
added rlimit-memlock.patch

Created an attachment (id=65964) [edit]
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