--pgp-sign-Multipart_Mon_Sep__4_23:33:28_2006-1
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

At Fri, 18 Aug 2006 09:43:40 +0200,
Pavel Cahyna wrote:
>=20
> On Sun, Aug 13, 2006 at 06:58:57PM +0200, Martin Husemann wrote:
> > On Sun, Aug 13, 2006 at 06:39:55PM +0400, Denis Lagno wrote:
> > > I do not know is it actually a bug.  It was discovered by my cat:)
> >=20
> > At work the cleaning woman discovered the same ;-)

This isn't a new problem -- it's been around since the dawn of UNIX, and
probably affected other systems long before, as well as affecting other
current systems with similar console paradigms.

> > > Is this behaviour fine?
> >=20
> > Yes, it is. Either remove the keyboard, or (easier) use "wsconsctl -w m=
ap" to
> > assign something harmless to the scroll lock key.
>=20
> It does not seem fine for syslogd to block if some of the output channels
> are blocked. Maybe it should use noblocking writes or something like that?

Actually syslogd (and everything else that might ever write to the
console device) _must_ block, at least in the generic case (and I don't
see any clean or nice way to identify the cases where it could be
allowed to ignore a true screen scroll lock without also screwing up a
user legitimately using such a feature).

Consider a serial console using software (XON/XOFF) flow control.
Nothing can be allowed to write while the output is blocked as any
characters transmitted at that time will most likely just be lost.

Buffering of course isn't any real solution either -- eventually all
possible buffer capacity will be filled and the result will be the same
regardless.

The issue is even more interesting when it is the kernel doing the
writing, expecially if the whole kernel blocks for some reason when the
write blocks.  I've seen several kinds of unix-based systems, including
recent versions of Solaris, come to a grinding halt some amount of time
after someone had accidentally hit Ctrl-S or the scroll-lock key,
etc. on their console terminals.

=46rom an operations point of view it has _always_ been extremely
important that critical server consoles always be securely connected to
very reliable terminals or terminal/console servers or similar; and/or
that their system keyboards be securely connected and carefully
protected from any and all adverse or unintended interference.

--=20
						Greg A. Woods

H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>       Secrets of the Weird <woods@weird.com>

--pgp-sign-Multipart_Mon_Sep__4_23:33:28_2006-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: WnEstLzNWnghkp1CmBKpc3eUH1FUSruF

iQA/AwUBRPzwC2J7XxTCWceFEQKqfQCgn3zbU94wkqZSeyp8pgtB6MR4U0wAoI4s
iDhqoyjdikFHmX43ws7YV+Jm
=7Kvl
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Mon_Sep__4_23:33:28_2006-1--