From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 21 03:19:41 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96D2E16A407 for ; Thu, 21 Feb 2008 03:19:41 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from www.pkgsrc-box.org (www.ostsee-abc.de [62.206.222.50]) by mx1.freebsd.org (Postfix) with ESMTP id 562B213C442 for ; Thu, 21 Feb 2008 03:19:41 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (www.pkgsrc-box.org [127.0.0.1]) by www.pkgsrc-box.org (Postfix) with ESMTP id 08757E7A3E0; Thu, 21 Feb 2008 03:19:40 +0000 (UTC) Received: by britannica.bec.de (Postfix, from userid 1000) id 81875175D0; Thu, 21 Feb 2008 04:18:56 +0100 (CET) Date: Thu, 21 Feb 2008 04:18:56 +0100 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20080221031856.GA17599@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org, ari edelkind References: <86068e730802181718s1ad50d3axeae0dde119ddcf92@mail.gmail.com> <47BA3334.4040707@andric.com> <86068e730802181954t52e4e05ay65e04c5f6de9b78a@mail.gmail.com> <20080219040912.GA14809@kobe.laptop> <47BCD34F.7010309@freebsd.org> <20080221023902.GI79355@episec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080221023902.GI79355@episec.com> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: ari edelkind Subject: Re: encrypted executables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 03:19:41 -0000 On Wed, Feb 20, 2008 at 09:39:03PM -0500, ari edelkind wrote: > Mind you, it's true that disabling core dumps with a resource limit > doesn't keep one from creating a core image using gcore, but since gcore > generally must either attach to a process using ptrace() or access > mapped code segments in the original binary (depending on the > implementation), it won't help in such a case, either. What prevents me from patching the kernel (!) to just ignore the resource limit? Nothing. Joerg