He wanted a to be able to panic() a machine from console without being
able to drop to DDB from console. I think this is because he believes
that DDB is a security problem. :-)
Well, I'm missing something: the beginning of this thread, so this may
not be 100% relevant, but I've just had the
On Sunday, 19 September 1999 at 18:29:34 +0900, Kazutaka YOKOTA wrote:
He wanted a to be able to panic() a machine from console without being
able to drop to DDB from console. I think this is because he believes
that DDB is a security problem. :-)
Well, I'm missing something: the beginning
That was exactly the suggestion the original poster made in his PR.
He also believed that assiging the PANIC function to a key
is no worse than having the DDB function key.
I think that's a valid statement. Sure, you can return from ddb,
whereas you can't from panic, but any abuse
On Monday, 20 September 1999 at 2:06:18 +0200, Leif Neland wrote:
That was exactly the suggestion the original poster made in his PR.
He also believed that assiging the PANIC function to a key
is no worse than having the DDB function key.
I think that's a valid statement. Sure, you can
[including -committers for political correctness]
On Friday, 17 September 1999 at 11:45:36 +0200, Sheldon Hearn wrote:
On Thu, 16 Sep 1999 13:30:30 MST, Doug wrote:
Would not the 'panic' option in DDB be enough to handle this, or
am I missing something?
He wanted a to be able to
[including -committers for political correctness]
On Friday, 17 September 1999 at 11:45:36 +0200, Sheldon Hearn wrote:
On Thu, 16 Sep 1999 13:30:30 MST, Doug wrote:
Would not the 'panic' option in DDB be enough to handle this, or
am I missing something?
He wanted a to be able to panic()
On Thu, 16 Sep 1999 13:30:30 MST, Doug wrote:
Would not the 'panic' option in DDB be enough to handle this, or
am I missing something?
He wanted a to be able to panic() a machine from console without being
able to drop to DDB from console. I think this is because he believes
that DDB
On Thu, 16 Sep 1999 13:30:30 MST, Doug wrote:
Would not the 'panic' option in DDB be enough to handle this, or
am I missing something?
He wanted a to be able to panic() a machine from console without being
able to drop to DDB from console. I think this is because he believes
that DDB
Number: 13721
Category: kern
Synopsis: There is no way to force system panic from console
[...]
Release:FreeBSD 3.3-RC
Organization:
Server
Environment:
Description:
Under some rare circumstances there is a real need to reboot system via kernel
's panic from the
Number: 13721
Category: kern
Synopsis: There is no way to force system panic from console
[...]
Release:FreeBSD 3.3-RC
Organization:
Server
Environment:
Description:
Under some rare circumstances there is a real need to reboot system via kernel
's panic from the system
In message 199909160948.saa02...@zodiac.mech.utsunomiya-u.ac.jp Kazutaka
YOKOTA writes:
: case _PANIC_KEY_
: #if !defined(SC_DISABLE_REBOOT) !defined(SC_DISABLE_PANIC)
: if (securelevel = 0)
: panic();
: #endif
: break;
:
: Any opinions?
As the originator suggested in his subsequent posting to the PR
database, we can defined panic key and handle it in syscons
as follows:
Would not the 'panic' option in DDB be enough to handle this, or
am I missing something? I'm not opposed to adding a panic() key combo,
just wondering
12 matches
Mail list logo
