From owner-freebsd-bugs@FreeBSD.ORG Sat Oct 15 17:30:25 2005 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4DCC016A420 for ; Sat, 15 Oct 2005 17:30:25 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AAF943D46 for ; Sat, 15 Oct 2005 17:30:25 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j9FHUO0W040693 for ; Sat, 15 Oct 2005 17:30:24 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j9FHUOVH040692; Sat, 15 Oct 2005 17:30:24 GMT (envelope-from gnats) Date: Sat, 15 Oct 2005 17:30:24 GMT Message-Id: <200510151730.j9FHUOVH040692@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: "db@trunet.dk" Cc: Subject: Re: bin/86405: /usr/bin/more segmentation fault X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "db@trunet.dk" List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2005 17:30:25 -0000 The following reply was made to PR bin/86405; it has been noted by GNATS. From: "db@trunet.dk" To: Nate Eldredge , bug-followup@freebsd.org Cc: Subject: Re: bin/86405: /usr/bin/more segmentation fault Date: Sat, 15 Oct 2005 19:26:24 +0000 On Thursday 13 October 2005 23:24, you wrote: > I think this might be a case of "don't do that". I will strongly disagree on "don't do that" fixes, when we are talking about a segmentation fault in a program, that is part of the base system. > It shouldn't be a security problem since if you can run less, you can > already execute arbitrary commands (try the ! command inside less). less > does have a "secure" mode in which these things are disabled, and in that > case the -k option is disabled as well. I agree that it shouldn't be a security problem though. Best regards db