From owner-freebsd-current@freebsd.org Thu Feb 2 12:39:00 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D86F6CCD122 for ; Thu, 2 Feb 2017 12:39:00 +0000 (UTC) (envelope-from freebsd@gomor.org) Received: from mail2.secure-side.com (sys2.secure-side.com [94.23.25.71]) by mx1.freebsd.org (Postfix) with ESMTP id 4846F1FE0 for ; Thu, 2 Feb 2017 12:38:59 +0000 (UTC) (envelope-from freebsd@gomor.org) Received: (qmail 62385 invoked by uid 0); 2 Feb 2017 12:32:16 -0000 Received: from unknown (HELO www.secure-side.com) (192.168.0.133) by smtpout.jail with ESMTP; 2 Feb 2017 12:32:16 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 02 Feb 2017 13:32:16 +0100 From: GomoR To: freebsd-current , owner-freebsd-current@freebsd.org Subject: Re: mlock and jail (Elasticsearch/Java use case) In-Reply-To: References: Message-ID: X-Sender: freebsd@gomor.org User-Agent: Roundcube Webmail/1.2.3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 12:39:00 -0000 Hello, Giving mlock support to jails would also allow Elasticsearch (Java-based) to run as a jailed process. In fact, Java can use a memory optimization trick for better performances by locking a specified amount of memory. Thus, Elasticsearch has the need for such a setting to let it run at its full power. Without this tunable, one cannot take advantage of this and Elasticsearch cannot run jailed to its full performance. Furthermore, putting it outside of a jail is less confortable regarding overall system security. Best regards, On 2017-02-02 02:31, Xin LI wrote: > I like this idea. > > Note that potentially your patch would make it possible for a jailed > root to DoS the whole system by locking too much of pages in memory. > I think it would be sensible to provide a per-jail flag to enable > doing it, or better, have some finer grained control (e.g. per jail > quota of permitted locked pages). > > Why did the application want to lock pages in main memory, though? > > On Wed, Feb 1, 2017 at 3:52 PM, Bruno Lauzé wrote: >> >> I would like to ask if there is a reason I would have to applythe >> patch below to make an application work in a jail. >> And who's bad? the app too intrusive or the bsd not flexible enough >> (allow.mlock?) >> >> >> Index: sys/kern/kern_jail.c >> =================================================================== >> --- sys/kern/kern_jail.c (revision 313033) >> +++ sys/kern/kern_jail.c (working copy) >> @@ -3340,6 +3340,11 @@ >> case PRIV_PROC_SETLOGINCLASS: >> return (0); >> >> >> + case PRIV_VM_MADV_PROTECT: >> + case PRIV_VM_MLOCK: >> + case PRIV_VM_MUNLOCK: >> + return (0); >> + >> default: >> >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org"