From owner-cvs-all Thu Sep 10 00:50:52 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA20416 for cvs-all-outgoing; Thu, 10 Sep 1998 00:50:52 -0700 (PDT) (envelope-from owner-cvs-all) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA20408; Thu, 10 Sep 1998 00:50:45 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id RAA03067; Thu, 10 Sep 1998 17:50:36 +1000 Date: Thu, 10 Sep 1998 17:50:36 +1000 From: Bruce Evans Message-Id: <199809100750.RAA03067@godzilla.zeta.org.au> To: bde@zeta.org.au, cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, jraynard@FreeBSD.ORG Subject: Re: cvs commit: src/etc rc Sender: owner-cvs-all@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Answering my own question: >The old code should have worked anyway, since it has two knobs (one >too many) - kern_securelevel_enable and kern_securelevel. People who >upgraded /etc/rc without upgrading /etc/rc.conf should have had an unset >kern_securelevel, which should have prevented the kernel securelevel >bein set. Why didn't it? Because of sloppy arg checking in /etc/rc, and sloppier arg checking in sysctl(8): $ test "" -ge 0 $ echo $? 1 # "" correctly(?) interpreted as 0 $ sysctl -w kern.securelevel="" kern.securelevel: -1 -> 0 # "" incorrectly interpreted as 0 The bug in sysctl is the usual one of blindly using atoi() on args that should be numeric. sysctl -w kern.securelevel=111111111111 kern.securelevel: -1 -> 2147483647 # blind overflow to INT_MAX Bruce