From owner-freebsd-bugs Tue Dec 2 08:56:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA13974 for bugs-outgoing; Tue, 2 Dec 1997 08:56:15 -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 IAA13969 for ; Tue, 2 Dec 1997 08:56:13 -0800 (PST) (envelope-from jin@george.lbl.gov) Received: (jin@localhost) by george.lbl.gov (8.6.10/8.6.5) id IAA25972; Tue, 2 Dec 1997 08:56:11 -0800 Date: Tue, 2 Dec 1997 08:56:11 -0800 From: Jin Guojun (ITG staff) Message-Id: <199712021656.IAA25972@george.lbl.gov> To: bugs@FreeBSD.ORG, joerg_wunsch@uriah.heep.sax.de Subject: Re: kern.securelevel auto from 0 to 1 ?bug/feature? Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > No. If you had read my mail, you knew the answer (and even the `how'). That solution is for a householder duty v.s. a president duty. Besides to startx first and then set securelevel to 1, I did not see there is another way to run X in secure mode. As you mentioned that the user cannot exit the X, which is awkward. Unless you want to restrict FreeBSD be used in single user environment, such as in a person or in a family, to keep X up means only one person can use a machine when the machine is booted up. This may be OK for some small group. What about thousands of machines sharing tens of servers are used by more than 10K users. We can let some staff lock their own screen, but not every one, typically not students to lock shared machines. Since level 1 is for multi-users mode, it should let user to access the basic resource. If level-2 prohibits X to start, I would not be bothered, but level-1 should not stop running X. I do not know X86 or BSD is the side to improve this issue, but I will spend some time to dig it out. So, if another one has some clue for how DDX been restricted by securelevel, I would appreciate to know. Thanks, -Jin