From owner-freebsd-bugs  Mon Dec  1 12:05:54 1997
Return-Path: <owner-freebsd-bugs>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id MAA10063
          for bugs-outgoing; Mon, 1 Dec 1997 12:05:54 -0800 (PST)
          (envelope-from owner-freebsd-bugs)
Received: from george.lbl.gov (george-2.lbl.gov [131.243.2.12])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA10037
          for <bugs@FreeBSD.ORG>; Mon, 1 Dec 1997 12:05:50 -0800 (PST)
          (envelope-from jin@george.lbl.gov)
Received: (jin@localhost) by george.lbl.gov (8.6.10/8.6.5) id MAA07847; Mon, 1 Dec 1997 12:05:18 -0800
Date: Mon, 1 Dec 1997 12:05:18 -0800
From: "Jin Guojun [ITG staff]" <jin@george.lbl.gov>
Message-Id: <199712012005.MAA07847@george.lbl.gov>
To: joerg_wunsch@uriah.heep.sax.de
Subject: Re: kern.securelevel auto from 0 to 1 ?bug/feature?
Cc: bugs@FreeBSD.ORG
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

}> So, I wonder if something can be fixed in FreeBSD kernel to prevent this
}> automatically securelevel jumping?
} 
}Well, if you want `insecure' mode, leave it as -1, and it won't bump
}itself.  That's why it's called ``Permanently insecure'' then.
} 
}Unlike the other BSD's, we decided to also plug some of the more
}common holes in the device drivers if you ever go to more than `0'.
}Due to the way X11 is currently implemented (which is unlikelyl to
}change within the near future), this precludes an Xserver from working
}in any of the higher securelevels.  OTOH, if you operate a server
}machine, the Xserver is probably not your biggest desire, but you
}might value the securelevel features...
} 
}-- 
}cheers, J"org

I am not sure what is your point. The secure level should do nothing
with Xserver AT ALL. The secure level is aimed to network ONLY.
I could not imagine if one is sitting at front of a server with the
console, the secure level is meaningful to this one. This person can
pick a hammer to break the entire machine; short the circiut; take out
the disk drive(s), and do whatever this one wants. The only prevention
for this problem is the key/lock/secure guard, not software.

My question is "why cannot the system let secure level stay at level 0
during the boot processing?" It can certainly be set to 0 after boot.
Would someone be happy to address this issue?

Thanks,

-Jin