Militantly FREE software support.
Militantly FREE software support.
NavigationUser loginSpam?See spam posts on this site? If so, please don't reply to the spam! Instead, just report the URL to the webmaster. |
X ignores keyboard and mouse input, but shows cursor movement (etch)A curious and rare (2 times since Etch became stable) X freeze or hang Problem: X ignores keyboard and mouse input, but shows cursor movement What happened: Viewing email message in icedove, right-click to save Ssh from another box to examine: Nothing unusual in /var/log. Kill the >From ssh: Restarted gdm. All is normal. This last line in Window manager is openbox. Has anyone experienced this behavior? Any ideas? (Next time I'll Thanks, Ralph Katz -- Bookmark/Search this post with: 
|
• Debian Weekly News - Essential reading for any Debian fan. • Documentation - Debian's own authoritative documentation, including installation docs. • FAQ - Got questions about Debian GNU/Linux? • From Windows to Debian - Tips for converting from Windows to Debian GNU/Linux • Package of the Day. • Security - Security information and alerts! • Bug System - Bug tracking and instructions on reporting bugs. • CD Images - Where/how to get Debian GNU/Linux CD images. • Mailing List Subscription - Dozens of Debian-specific support mailing lists! • Mailing List Archives - Searchable archives of Debian's mailing lists. • Free Software Guidelines - Learn Debian's idea of what "free" software really is. • Package Listings - A very valuable tool: searchable, integrated with bug reports. • Apt-Get Sources - Sources for *.debs which are not official Debian packages. • Backports - Unofficial new software packages that have been "back-ported" to work with the Debian stable/official release. • Developer's Corner - Info about the people behind Debian, policies, and how to package *.deb files.
X ignores keyboard and mouse input, but shows cursor movement (e
On 9/14/07, Ralph Katz wrote:
> A curious and rare (2 times since Etch became stable) X freeze or hang
> has me wondering what to do.
>
> Problem: X ignores keyboard and mouse input, but shows cursor movement
> and running apps update normally on-screen in visible windows (gkrellm,
> gaim, etc).
>
> What happened: Viewing email message in icedove, right-click to save
> image from the email, no response to mouse clicks, mouse wheel or
> keyboard input, but mouse cursor movement appears normal. icedove
> continues to fetch new mail on schedule. The identical symptoms
> happened once before while composing in icedove.
>
> Ssh from another box to examine: Nothing unusual in /var/log. Kill the
> icedove processes. Screen shows icedove closing, then switches to VT1
> apparently from a queued earlier attempt. Keyboard now accepts
> ctrl-alt-F7 back to X, but again is frozen to all input in X! Just as
> it was before killing icedove.
>
> >From ssh: Restarted gdm. All is normal. This last line in
> /var/log/Xorg.0.log.old is the only thing I could find that looked
> different:
> FreeFontPath: FPE "/usr/share/fonts/X11/misc" refcount is 2, should be
> 1; fixing.
>
> Window manager is openbox.
>
> Has anyone experienced this behavior? Any ideas? (Next time I'll
> remember to check .xsession-errors.)
>
> Thanks,
>
> Ralph Katz
I have experienced somewhat similar freezes in Unstable. The
differences are that I am using SeaMonkey 2.0a1pre (Nightlies)
for web browsing, I have never managed even a VT switch and
I am using Fluxbox. Oh, and I don't use a session manager
(GDM, etc). This has happened at least six times.
I know the Font refcount thing is not related because it always
says that when I exit X.
With such a hard freeze, that happens so sporadically, I feel
(as a non-programmer) helpless to try to figure it out.
Sorry I can't help.
Cheers,
Kelly
--
X ignores keyboard and mouse input, but shows cursor movement (e
On 09/14/2007 03:19 PM, Kelly Clowers wrote:
> On 9/14/07, Ralph Katz wrote:
>> A curious and rare (2 times since Etch became stable) X freeze or hang
>> has me wondering what to do.
>>
>> Problem: X ignores keyboard and mouse input, but shows cursor movement
>> and running apps update normally on-screen in visible windows (gkrellm,
>> gaim, etc).
>>
>> What happened: Viewing email message in icedove, right-click to save
>> image from the email, no response to mouse clicks, mouse wheel or
>> keyboard input, but mouse cursor movement appears normal. icedove
>> continues to fetch new mail on schedule. The identical symptoms
>> happened once before while composing in icedove.
>>
>> Ssh from another box to examine: Nothing unusual in /var/log. Kill the
>> icedove processes. Screen shows icedove closing, then switches to VT1
>> apparently from a queued earlier attempt. Keyboard now accepts
>> ctrl-alt-F7 back to X, but again is frozen to all input in X! Just as
>> it was before killing icedove.
>>
>> >From ssh: Restarted gdm. All is normal. This last line in
>> /var/log/Xorg.0.log.old is the only thing I could find that looked
>> different:
>> FreeFontPath: FPE "/usr/share/fonts/X11/misc" refcount is 2, should be
>> 1; fixing.
>>
>> Window manager is openbox.
>>
>> Has anyone experienced this behavior? Any ideas? (Next time I'll
>> remember to check .xsession-errors.)
>>
>> Thanks,
>>
>> Ralph Katz
>
> I have experienced somewhat similar freezes in Unstable. The
> differences are that I am using SeaMonkey 2.0a1pre (Nightlies)
> for web browsing, I have never managed even a VT switch and
> I am using Fluxbox. Oh, and I don't use a session manager
> (GDM, etc). This has happened at least six times.
>
> I know the Font refcount thing is not related because it always
> says that when I exit X.
>
> With such a hard freeze, that happens so sporadically, I feel
> (as a non-programmer) helpless to try to figure it out.
>
> Sorry I can't help.
>
>
> Cheers,
> Kelly
Kelly, thanks for responding. Looking further back in my notes, in
April of 2004, I had the same problem running sid. In that case, ssh'd
in to kill off processes one at a time to isolate the culprit, which was
gaim. Problem never re-occurred until what I described above.
And let me clarify that the VT switch was /after/ killing icedove. So
during the freeze, the box was inaccessible locally.
Regards,
Ralph (also a non-programmer)
--
X ignores keyboard and mouse input, but shows cursor movement (e
On Fri, 14 Sep 2007, Ralph Katz wrote:
>>> Problem: X ignores keyboard and mouse input, but shows cursor movement
>>> and running apps update normally on-screen in visible windows (gkrellm,
>>> gaim, etc).
I regularly see a similar problem on several boxen - and have for
quite some time.
* Mouse cursor moves, and can select windows (maximize/minimize)
* Can not select items in a window (firefox/etc) with mouse
* No keyboard response in any window
All boxes are Sid - kept current daily. I first thought it might be
hibernate/resume related - but when it started happening on my desktop
I discounted that :)
It may, however, be power related - I don't recall seeing the issue
before I enabled conservative(amd_64 desktop) or on-demand(intel_64)
power management.
On the laptop, things are often fine until after a resume, I run ntpdate
to correct the clock.
CTRL-ALT-BACKSPACE (killing the WindowMaker session) always gets me out
of the problem, but it isn't fun.
--
Rick Nelson
`You have been unsubscribed from the high energy personal
protection devices mailing list'
I dont remember getting into the mailing list
--
X ignores keyboard and mouse input, but shows cursor movement (e
On 9/14/07, Richard A Nelson wrote:
>
> I regularly see a similar problem on several boxen - and have for
> quite some time.
> * Mouse cursor moves, and can select windows (maximize/minimize)
> * Can not select items in a window (firefox/etc) with mouse
> * No keyboard response in any window
>
> All boxes are Sid - kept current daily. I first thought it might be
> hibernate/resume related - but when it started happening on my desktop
> I discounted that :)
>
> It may, however, be power related - I don't recall seeing the issue
> before I enabled conservative(amd_64 desktop) or on-demand(intel_64)
> power management.
>
> On the laptop, things are often fine until after a resume, I run ntpdate
> to correct the clock.
>
> CTRL-ALT-BACKSPACE (killing the WindowMaker session) always gets me out
> of the problem, but it isn't fun.
I don't have any power management going on, and it seems like
the freeze is harder - ctrl-alt-backspace and C-A-D have no effect
at all, even after remotely killing SeaMonkey (no window selection,
either). And remotely killing X doesn't change any thing either.
Sometime the power button "soft off" (clean shutdown) works but
once only "hard off" worked.
I the past I have encountered freezes that could be solved by
C-A-BS or by remotely killing the process, but I have only had
this harder freeze since around the time etch went stable.
Cheers,
Kelly
--
X ignores keyboard and mouse input, but shows cursor movement (e
On Fri, Sep 14, 2007 at 03:37:15PM -0700, Kelly Clowers wrote:
> On 9/14/07, Richard A Nelson wrote:
> >
> > I regularly see a similar problem on several boxen - and have for
> > quite some time.
> > * Mouse cursor moves, and can select windows (maximize/minimize)
> > * Can not select items in a window (firefox/etc) with mouse
> > * No keyboard response in any window
> >
> > All boxes are Sid - kept current daily. I first thought it might be
> > hibernate/resume related - but when it started happening on my desktop
> > I discounted that :)
> >
> > It may, however, be power related - I don't recall seeing the issue
> > before I enabled conservative(amd_64 desktop) or on-demand(intel_64)
> > power management.
> >
> > On the laptop, things are often fine until after a resume, I run ntpdate
> > to correct the clock.
> >
> > CTRL-ALT-BACKSPACE (killing the WindowMaker session) always gets me out
> > of the problem, but it isn't fun.
>
> I don't have any power management going on, and it seems like
> the freeze is harder - ctrl-alt-backspace and C-A-D have no effect
> at all, even after remotely killing SeaMonkey (no window selection,
> either). And remotely killing X doesn't change any thing either.
> Sometime the power button "soft off" (clean shutdown) works but
> once only "hard off" worked.
>
> I the past I have encountered freezes that could be solved by
> C-A-BS or by remotely killing the process, but I have only had
> this harder freeze since around the time etch went stable.
>
just a word to the wise when dealing with these issues... magic sysrq
key, be sure to google it. The two that are most useful, to me anyway,
are
Alt-sysrq-s to sync the filesystems (you'll see your drive light come
on briefly and you;ll get a console message if you happen to be in
one.)
alt-sysrq-b to reboot.
A
X ignores keyboard and mouse input, but shows cursor movement (e
On Fri, Sep 14, 2007 at 04:24:50PM -0700, Andrew Sackville-West wrote:
> Alt-sysrq-s to sync the filesystems (you'll see your drive light come
> on briefly and you;ll get a console message if you happen to be in
> one.)
The console I used to test this became unusable. The rest of the system
seems ok though.
Regards,
Andrei
--
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)
X ignores keyboard and mouse input, but shows cursor movement (e
On Sun, Sep 16, 2007 at 07:42:04AM +0300, Andrei Popescu wrote:
> On Fri, Sep 14, 2007 at 04:24:50PM -0700, Andrew Sackville-West wrote:
>
> > Alt-sysrq-s to sync the filesystems (you'll see your drive light come
> > on briefly and you;ll get a console message if you happen to be in
> > one.)
>
> The console I used to test this became unusable. The rest of the system
> seems ok though.
how do you mean? Were you testing alt-sysrq-s? I think its something
that should only be done as a last resort before pulling the plug on a
locked-up box. I will note that the few times I've used it, I've not
had any "recovering journal" messages upon reboot, which I think is
the whole point. You box is so borked that you've got to pull the
plug, so try and sync the file system first. If the console is no
longer usable after doing this, well, you were taking the box down
forcibly anyway...
A
--
current song: The Killers - Midnight Show
X ignores keyboard and mouse input, but shows cursor movement (e
On Tue, Sep 18, 2007 at 10:14:36AM -0700, Andrew Sackville-West wrote:
> On Sun, Sep 16, 2007 at 07:42:04AM +0300, Andrei Popescu wrote:
> > On Fri, Sep 14, 2007 at 04:24:50PM -0700, Andrew Sackville-West wrote:
> >
> > > Alt-sysrq-s to sync the filesystems (you'll see your drive light come
> > > on briefly and you;ll get a console message if you happen to be in
> > > one.)
> >
> > The console I used to test this became unusable. The rest of the system
> > seems ok though.
>
> how do you mean? Were you testing alt-sysrq-s? I think its something
Yes
> that should only be done as a last resort before pulling the plug on a
> locked-up box. I will note that the few times I've used it, I've not
> had any "recovering journal" messages upon reboot, which I think is
> the whole point. You box is so borked that you've got to pull the
> plug, so try and sync the file system first. If the console is no
> longer usable after doing this, well, you were taking the box down
> forcibly anyway...
Of course, for the "normal" case there is sync. BTW, that console is
still unusable, but the rest of the system is ok (uptime 10 days+)
Regards,
Andrei
--
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)
X ignores keyboard and mouse input, but shows cursor movement (e
On Tue, Sep 18, 2007 at 08:44:16PM +0300, Andrei Popescu wrote:
> On Tue, Sep 18, 2007 at 10:14:36AM -0700, Andrew Sackville-West wrote:
> > On Sun, Sep 16, 2007 at 07:42:04AM +0300, Andrei Popescu wrote:
> > > On Fri, Sep 14, 2007 at 04:24:50PM -0700, Andrew Sackville-West wrote:
> > >
> > > > Alt-sysrq-s to sync the filesystems (you'll see your drive light come
> > > > on briefly and you;ll get a console message if you happen to be in
> > > > one.)
> > >
> > > The console I used to test this became unusable. The rest of the system
> > > seems ok though.
> >
> > how do you mean? Were you testing alt-sysrq-s? I think its something
>
> Yes
>
> > that should only be done as a last resort before pulling the plug on a
> > locked-up box. I will note that the few times I've used it, I've not
> > had any "recovering journal" messages upon reboot, which I think is
> > the whole point. You box is so borked that you've got to pull the
> > plug, so try and sync the file system first. If the console is no
> > longer usable after doing this, well, you were taking the box down
> > forcibly anyway...
>
> Of course, for the "normal" case there is sync. BTW, that console is
> still unusable, but the rest of the system is ok (uptime 10 days+)
huh. can you HUP the getty for that console (are we talking about a VT
here or a serial console somewhere?)? Well, sorry about that. I was
trying to help out the OP with their hard locks and drastic rebooting
by hopefully saving their filesystems...
A
--
current song: Ice-T - The Hunted Child
X ignores keyboard and mouse input, but shows cursor movement (e
On Tue, Sep 18, 2007 at 11:16:04AM -0700, Andrew Sackville-West wrote:
> > Of course, for the "normal" case there is sync. BTW, that console is
> > still unusable, but the rest of the system is ok (uptime 10 days+)
>
> huh. can you HUP the getty for that console (are we talking about a VT
> here or a serial console somewhere?)? Well, sorry about that. I was
No need to be sorry :) I consider the benefit of learning something new
more important than a reboot on my laptop. I'm not using consoles very
much anyway, because I run X with a lot of terms (5 at the moment) to
use Alt-Tab switching (old Windows habit).
Regards,
Andrei
--
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)
Magic SysRq [was X ignores keyboard and mouse input, but shows
On 09/14/2007 07:24 PM, Andrew Sackville-West wrote:
> just a word to the wise when dealing with these issues... magic sysrq
> key, be sure to google it. The two that are most useful, to me anyway,
> are
>
> Alt-sysrq-s to sync the filesystems (you'll see your drive light come
> on briefly and you;ll get a console message if you happen to be in
> one.)
>
> alt-sysrq-b to reboot.
This is new to me; never knew what that key did!
Etch has sysrq enabled. However, the security implications should be
documented. SysRq isn't even mentioned in securing-debian-howto. It's
mentioned incorrectly as "default installation kernels are not compiled
with this option" in debian reference (
http://qref.sourceforge.net/).
Regards,
Ralph
--
Magic SysRq [was X ignores keyboard and mouse input, but shows
On Sun, Sep 16, 2007 at 09:06:49AM -0400, Ralph Katz wrote:
> On 09/14/2007 07:24 PM, Andrew Sackville-West wrote:
>
> > just a word to the wise when dealing with these issues... magic sysrq
> > key, be sure to google it. The two that are most useful, to me anyway,
> > are
> >
> > Alt-sysrq-s to sync the filesystems (you'll see your drive light come
> > on briefly and you;ll get a console message if you happen to be in
> > one.)
> >
> > alt-sysrq-b to reboot.
>
> This is new to me; never knew what that key did!
>
> Etch has sysrq enabled. However, the security implications should be
> documented. SysRq isn't even mentioned in securing-debian-howto. It's
> mentioned incorrectly as "default installation kernels are not compiled
> with this option" in debian reference (
> http://qref.sourceforge.net/).
out of curiousity, what are the security implications? sysrq requires
physical access to the machine (well, at least the keyboard) and
therefore security is pretty much out the window. or is there some way
to trigger these events from a remote location?
A
--
current song: The Killers - Midnight Show
Magic SysRq [was X ignores keyboard and mouse input, but sho
On 09/18/2007 01:12 PM, Andrew Sackville-West wrote:
> On Sun, Sep 16, 2007 at 09:06:49AM -0400, Ralph Katz wrote:
>> On 09/14/2007 07:24 PM, Andrew Sackville-West wrote:
>>
>>> just a word to the wise when dealing with these issues... magic sysrq
>>> key, be sure to google it. The two that are most useful, to me anyway,
>>> are
>>>
>>> Alt-sysrq-s to sync the filesystems (you'll see your drive light come
>>> on briefly and you;ll get a console message if you happen to be in
>>> one.)
>>>
>>> alt-sysrq-b to reboot.
>> This is new to me; never knew what that key did!
>>
>> Etch has sysrq enabled. However, the security implications should be
>> documented. SysRq isn't even mentioned in securing-debian-howto. It's
>> mentioned incorrectly as "default installation kernels are not compiled
>> with this option" in debian reference (
>> http://qref.sourceforge.net/).
>
> out of curiousity, what are the security implications? sysrq requires
> physical access to the machine (well, at least the keyboard) and
> therefore security is pretty much out the window. or is there some way
> to trigger these events from a remote location?
Andrew, surely you're kidding! :)
This is a local vulnerability, yes. No worse than pulling the plug. Of
course that IS the problem. Only keyboard access is needed for this.
To test, I booted a second etch computer which comes up to a gnome
desktop, and hit alt-sysrq-i. The display shows a nasty pink colored
image... Next was to hit alt-sysrq-b which must be the linux 3-finger
salute known to windows people.
And yes, I've filed a bug on this (442512, 442893).
Regards,
Ralph
--
Magic SysRq [was X ignores keyboard and mouse input, but shows
On Tue, Sep 18, 2007 at 02:19:30PM -0400, Ralph Katz wrote:
> On 09/18/2007 01:12 PM, Andrew Sackville-West wrote:
> > On Sun, Sep 16, 2007 at 09:06:49AM -0400, Ralph Katz wrote:
> >> On 09/14/2007 07:24 PM, Andrew Sackville-West wrote:
> >>
> >>> just a word to the wise when dealing with these issues... magic sysrq
> >>> key, be sure to google it. The two that are most useful, to me anyway,
> >>> are
> >>>
> >>> Alt-sysrq-s to sync the filesystems (you'll see your drive light come
> >>> on briefly and you;ll get a console message if you happen to be in
> >>> one.)
> >>>
> >>> alt-sysrq-b to reboot.
> >> This is new to me; never knew what that key did!
> >>
> >> Etch has sysrq enabled. However, the security implications should be
> >> documented. SysRq isn't even mentioned in securing-debian-howto. It's
> >> mentioned incorrectly as "default installation kernels are not compiled
> >> with this option" in debian reference (
> >> http://qref.sourceforge.net/).
> >
> > out of curiousity, what are the security implications? sysrq requires
> > physical access to the machine (well, at least the keyboard) and
> > therefore security is pretty much out the window. or is there some way
> > to trigger these events from a remote location?
>
> Andrew, surely you're kidding! :)
I wasn't kidding, but I see now why I look stupid... ;) My limited
security knowledge centers around remote vulnerabilities. The
computers I secure are in my house with little to no information that
needs securing that couldn't easily be gotten elsewhere in the
house. So local vulnerabilities are a given for me. The most I do is
password the screensaver so the kids can't muck around with programs I
may have open. Heck, I don't even have the case closed up on my main
machine most of the time, much less locking the case or bolting it to
the table.
So in my limited world, unless its a remote vulnerability, I don't
worry about it. Interestingly, at work i have a couple machines that I
keep locked down pretty tightly for local exploits as well, but have
never considered sysrq a problem. I'm not sure, running sid, that
turning off sysrq is all that good an idea though. probably better to
make sure the system will only boot one way (bios passwords etc) so
that someone can't boot a cd and leave it at that. They can
alt-sysrq-b all they want. I wan't to have access to that function as
well.
>
> This is a local vulnerability, yes. No worse than pulling the plug. Of
> course that IS the problem. Only keyboard access is needed for this.
of course.
>
> To test, I booted a second etch computer which comes up to a gnome
> desktop, and hit alt-sysrq-i. The display shows a nasty pink colored
> image... Next was to hit alt-sysrq-b which must be the linux 3-finger
> salute known to windows people.
>
> And yes, I've filed a bug on this (442512, 442893).
good. As I type this the potentials are dawning on me...
A
--
current song: Weezer - Jamie/Live and Acoustic
Magic SysRq [was X ignores keyboard and mouse input, but shows
On Sep 18, 2007, at 11:19 AM, Ralph Katz wrote:
> This is a local vulnerability, yes. No worse than pulling the
> plug. Of
> course that IS the problem. Only keyboard access is needed for this.
>
> To test, I booted a second etch computer which comes up to a gnome
> desktop, and hit alt-sysrq-i. The display shows a nasty pink colored
> image... Next was to hit alt-sysrq-b which must be the linux 3-finger
> salute known to windows people.
Hmm. I see what you're getting at, but is this really any worse than
the default ctrl-alt-del behavior? (Or is there a security warning
about that, too?)
Frankly, if someone has physical access, a reboot is just about the
least of your worries. It's pretty trivial for them to gain root
access if they have physical access to the hardware.
--
Magic SysRq [was X ignores keyboard and mouse input, but shows
On 09/18/2007 05:17 PM, David Brodbeck wrote:
>
> On Sep 18, 2007, at 11:19 AM, Ralph Katz wrote:
>> This is a local vulnerability, yes. No worse than pulling the plug. Of
>> course that IS the problem. Only keyboard access is needed for this.
>>
>> To test, I booted a second etch computer which comes up to a gnome
>> desktop, and hit alt-sysrq-i. The display shows a nasty pink colored
>> image... Next was to hit alt-sysrq-b which must be the linux 3-finger
>> salute known to windows people.
>
> Hmm. I see what you're getting at, but is this really any worse than
> the default ctrl-alt-del behavior? (Or is there a security warning
> about that, too?)
>
> Frankly, if someone has physical access, a reboot is just about the
> least of your worries. It's pretty trivial for them to gain root access
> if they have physical access to the hardware.
It is worse precisely because it's undocumented. The default
ctrl-alt-del behavior is documented, so not an issue.
One might ask whether the default ON for sysrq is appropriate for
Stable. While I don't think it is, my bigger problem is with the
absence of warnings or user documentation. This is critical for a
distro that cares about its users which is why I filed bug 442512.
Perhaps this is more an issue to me as a non-programmer...
And yes, physical access is problematic.
Regards,
Ralph
--
Magic SysRq [was X ignores keyboard and mouse input, but shows
On Tue, Sep 18, 2007 at 06:05:05PM -0400, Ralph Katz wrote:
> On 09/18/2007 05:17 PM, David Brodbeck wrote:
> >
> > On Sep 18, 2007, at 11:19 AM, Ralph Katz wrote:
> >> This is a local vulnerability, yes. No worse than pulling the plug. Of
> >> course that IS the problem. Only keyboard access is needed for this.
> >>
> >> To test, I booted a second etch computer which comes up to a gnome
> >> desktop, and hit alt-sysrq-i. The display shows a nasty pink colored
> >> image... Next was to hit alt-sysrq-b which must be the linux 3-finger
> >> salute known to windows people.
> >
> > Hmm. I see what you're getting at, but is this really any worse than
> > the default ctrl-alt-del behavior? (Or is there a security warning
> > about that, too?)
> >
> > Frankly, if someone has physical access, a reboot is just about the
> > least of your worries. It's pretty trivial for them to gain root access
> > if they have physical access to the hardware.
>
> It is worse precisely because it's undocumented. The default
> ctrl-alt-del behavior is documented, so not an issue.
>
> One might ask whether the default ON for sysrq is appropriate for
> Stable. While I don't think it is, my bigger problem is with the
> absence of warnings or user documentation. This is critical for a
> distro that cares about its users which is why I filed bug 442512.
> Perhaps this is more an issue to me as a non-programmer...
>
your point is that an undocumented method of rebooting the computer is
a security issue not because of the rebooting but because of the lack
of documentation of a method of rebooting. I agree. you are right to
report this.
I'm not sure how I feel about sysrq being on or off by default, but
documenting its existence is vastly more important than its default
configuration.
A
Magic SysRq [was X ignores keyboard and mouse input, but shows
On Wed, Sep 19, 2007 at 09:56:35AM -0700, Andrew Sackville-West wrote:
> your point is that an undocumented method of rebooting the computer is
> a security issue not because of the rebooting but because of the lack
> of documentation of a method of rebooting. I agree. you are right to
> report this.
>
> I'm not sure how I feel about sysrq being on or off by default, but
> documenting its existence is vastly more important than its default
> configuration.
I think that it should be off by default, but set up in the kernel to be
configurable with sysctl or something. Some people find it very useful
who for the reason of testing a default kernel don't want to compile a
custom one with the feature enabled. Others of us don't want to compile
a kernel period but don't need the functionality.
Isn't it a basic tennent of security that unused
service/features/whatever should be turned off so that some unknown
problem can't be exploited before it is discovered?
Doug.
--
X ignores keyboard and mouse input, but shows cursor movement (e
Ralph Katz wrote:
>Problem: X ignores keyboard and mouse input, but shows cursor movement
>and running apps update normally on-screen in visible windows (gkrellm,
>gaim, etc).
Although you're not using Metacity, maybe have a look at bug #427406 [0],
the symptoms are exactly the same.
Greetings,
Claudius
[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=427406
--
Mail: ICQ: 224491597 ,= ,-_-. =.
Jabber: SIP: ((_/)o o(\_))
MSN: Nightfall.org:23 Claudius `-'(. .)`-'
Yahoo: Using: [Opera|Gaim|*]@Debian \_/ GNU
--