From owner-freebsd-security@FreeBSD.ORG  Tue Apr 30 19:37:04 2013
Return-Path: <owner-freebsd-security@FreeBSD.ORG>
Delivered-To: freebsd-security@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 by hub.freebsd.org (Postfix) with ESMTP id 5E5E58F3;
 Tue, 30 Apr 2013 19:37:04 +0000 (UTC)
 (envelope-from brett@lariat.org)
Received: from lariat.net (lariat.net [66.62.230.51])
 by mx1.freebsd.org (Postfix) with ESMTP id D74961502;
 Tue, 30 Apr 2013 19:37:03 +0000 (UTC)
Received: from Toshi.lariat.org (IDENT:ppp1000.lariat.net@lariat.net
 [66.119.58.2] (may be forged))
 by lariat.net (8.9.3/8.9.3) with ESMTP id NAA02519;
 Tue, 30 Apr 2013 13:36:59 -0600 (MDT)
Message-Id: <201304301936.NAA02519@lariat.net>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 30 Apr 2013 13:36:52 -0600
To: Chris Rees <utisoft@gmail.com>, Glen Barber <gjb@freebsd.org>,
 Colin Percival <cperciva@freebsd.org>
From: Brett Glass <brett@lariat.org>
Subject: Re: FreeBSD Security Advisory FreeBSD-SA-13:05.nfsserver
In-Reply-To: <CADLo839_J40E4O2s7Af3r1stH98B-fjKtBwmNovaPfY7peqi7Q@mail.g
 mail.com>
References: <201304292055.r3TKtcEs039958@freefall.freebsd.org>
 <201304292208.QAA16119@lariat.net>
 <20130430034603.GF1588@glenbarber.us>
 <201304300416.WAA20729@lariat.net>
 <20130430042415.GG1588@glenbarber.us>
 <CADLo839_J40E4O2s7Af3r1stH98B-fjKtBwmNovaPfY7peqi7Q@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: freebsd-security@freebsd.org
X-BeenThere: freebsd-security@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: "Security issues \[members-only posting\]"
 <freebsd-security.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-security>, 
 <mailto:freebsd-security-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-security>
List-Post: <mailto:freebsd-security@freebsd.org>
List-Help: <mailto:freebsd-security-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-security>, 
 <mailto:freebsd-security-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Apr 2013 19:37:04 -0000

This is one of several reasons why one would expect freebsd-update(8) to be
considerate of a custom kernel: it is documented as knowing about
/boot/GENERIC as the place to put he GENERIC kernel if one builds a
custom one.

Also, I don't think that freebsd-update(8) should, in the course of a normal
update, create a situation where the system is not be able to reboot. This
would have been the case with the system I updated, had I not 
caught the problem.

I daresay that a system that stops working after a routine update 
is a violation
of POLA. ;-)

In my case, the GENERIC kernel was installed in place of the custom 
one, without
modules the system needed -- in either loadable or built-in form. It's easy to
prevent this by modifying /boot/GENERIC (which freebsd-update is 
supposed to know
about) instead of overwriting the custom kernel... and then advising the
administrator that a new build might be needed.

--Brett Glass

At 10:26 AM 4/30/2013, Chris Rees wrote:

>I agreed with Glen, but when checking the docs it turns out that they say
>that freebsd-update will detect a kernel in /boot/GENERIC:
>
>http://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html
>
>Are the docs wrong, or is this only in new freebsd-update?
>
>Chris
>_______________________________________________
>freebsd-security@freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-security
>To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"