From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 31 00:29:58 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0AC49E7D for ; Thu, 31 Oct 2013 00:29:58 +0000 (UTC) (envelope-from dt71@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 97F802F70 for ; Thu, 31 Oct 2013 00:29:57 +0000 (UTC) Received: from [157.181.98.186] ([157.181.98.186]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LlqNY-1WAjqd3e88-00ZN8c for ; Thu, 31 Oct 2013 01:29:55 +0100 Message-ID: <5271A465.2030206@gmx.com> Date: Thu, 31 Oct 2013 01:29:25 +0100 From: dt71@gmx.com User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Firefox/24.0 SeaMonkey/2.21 MIME-Version: 1.0 To: Colin Percival , freebsd-hackers@freebsd.org Subject: Re: Automated submission of kernel panic reports References: <526F8EB3.1040205@freebsd.org> In-Reply-To: <526F8EB3.1040205@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:mN81ewHeaErx4AasDG/B/cnTYMq77Bg12NO+ne8qlrSXmBT05Pm U2jTucAFbIVtVv+x3gBo0vLkqKNOPLNu4eSRKXE/joId8P1g1FbIXehMEMBPIcf3Ppt5rBI 1A0cpyZ7FFJF17+W2PG8JIfaPoLw5K/Ix/+6EB65/ZyoTarqK33m5L5Q/kNcv17OGoMJdXN uEJdPKljdA0OBYpgMUU+w== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 00:29:58 -0000 Notes/advice/recommendations/proposals/questions/whatever: This smells of having a potential to make an admin accidentally transmit undesired information, as well as adding some attack surface. Without testing, I bet that a reguler user will be able to read the panicmail.N file (which will contain the textdump) -- the umask/permissions are not set up properly. I very much dislike the non-use of double quotes around variable expansions and things like that in the shell code. The return code of /usr/local/bin/pkesh should be handled. Place a comment to the location in the code where an admin could put an add-on script that can automatically modify the text to be submitted (both automatic and confirmed mode). What if the /var/crash/{info,vmcore}.last symlinks were used as a basis for selecting the last dump, instead of the current "$((`cat bounds` - 1))"/"$1" method? What's wrong with "our" /bin/sh? If a temporary file is used for kgdb commands anyway, would it not be cleaner to use ``-x ${tmpfile}'' instead of input-piping? How about: ${panicmail_sendto} could be "Full Name "? "# Remove temporary file" is a bit superfluous. Choose a consistent commenting style: either use periods/fullstops, or don't. I'd personally use ``>'' instead of ``>>'' first in panicmail_gather().