Bug 14941

Summary: /etc/init vs kern.securelevel incoherence
Product: Base System Reporter: Cyrille Lefevre <root>
Component: kernAssignee: kato
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 3.3-STABLE   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
file.diff
none
file.diff none

Description Cyrille Lefevre 1999-11-17 13:10:00 UTC
	the init(8) manual says :

	Any super-user process can raise the security level, but only
	init can lower it.
	...
	If the security level is initially -1, then init leaves it
	unchanged.  Otherwise, init arranges to run the system in
	level 0 mode while single-user and in level 1 mode while
	multi-user. 

	but in the kernel says :

	in function sysctl_kern_securelvl in /sys/kern/kern_mib.c :

		if (securelevel > 1 && level < securelevel)
			return (EPERM);

	as well as the sysctl(3) manual and some other docs :

	KERN_SECURELVL
		The system security level.  This level may be raised
		by processes with appropriate privilege.  It may not
		be lowered.

	so, if you have a security level greater or equal to 1,
	even when going to single-user mode, you cannot lower
	the security level to 0 to install a new kernel and you
	have reboot into single-user or to set the
	kern_securelevel_enable to NO in the /etc/rc.conf file,
	then reboot.

Fix: # diff -rcb kern_mib.c.orig kern_mib.c
a much portable solution would be :

# diff -rcb kern_mib.c.orig kern_mib.c
How-To-Repeat: 
	in /etc/rc.conf :

	kern_securelevel_enable="YES"
	kern_securelevel="0"

	boot to multi-user mode then switch to single user mode using :

	init 1

	you got a syslog message saying :

	cannot change kernel security level from 1 to 0: Permission denied.
Comment 1 Sheldon Hearn freebsd_committer freebsd_triage 1999-11-17 13:19:41 UTC
State Changed
From-To: open->suspended

This situation was dealt with in rev 1.19 of init.8 and rev 1.36 of 
init.c, although these changes have not yet been merged back to the  
stable branch.  I'm leaving this PR in the suspended state as an 
kato has other such 
PR's lying around, he can close this as a duplicate. 


Comment 2 Sheldon Hearn freebsd_committer freebsd_triage 1999-11-17 13:19:41 UTC
Responsible Changed
From-To: freebsd-bugs->kato

kato's commit to CURRENT. 
Comment 3 kato freebsd_committer freebsd_triage 1999-12-04 14:21:10 UTC
State Changed
From-To: suspended->closed

The inconsistency between the manual page and init.c was solved in both  
current and RELENG_3.  FreeBSD's init cannot downgrade securelevel.