The root cause for a recent problem reported on misc@ [0] was determined to be setting kern.securelevel=2 in sysctl.conf. [1]
To perhaps prevent the provisioning error from happening to others, I propose the following clarification to securelevel(7). I percieve the setting as little more than an attractive nuisance and have never used it myself. [0] http://marc.info/?t=143807537400003&r=1&w=2 [1] http://daemonforums.org/showthread.php?t=9262 Index: securelevel.7 =================================================================== RCS file: /systems/cvs/src/share/man/man7/securelevel.7,v retrieving revision 1.25 diff -u -p -u -r1.25 securelevel.7 --- securelevel.7 9 Oct 2014 04:23:04 -0000 1.25 +++ securelevel.7 1 Aug 2015 13:52:35 -0000 @@ -155,6 +155,12 @@ and helps ensure the integrity of logs. Precision timekeeping is not affected because the clock may still be slowed. .Pp +Highly secure mode, if set at boot time, should be done by means of +.Xr rc.securelevel 8 , +rather than by means of +.Xr sysctl.conf 5 , +as the latter would set the mode too early in the boot process. +.Pp Because securelevel can be modified with the in-kernel debugger .Xr ddb 4 , a convenient means of locking it off (if present) is provided
