From owner-freebsd-current Fri Aug 23 15:39:14 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43EC337B400 for ; Fri, 23 Aug 2002 15:39:12 -0700 (PDT) Received: from turbine.trit.org (turbine.trit.org [63.198.170.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id 611C243E6A for ; Fri, 23 Aug 2002 15:39:11 -0700 (PDT) (envelope-from dima@trit.org) Received: from turbine.trit.org (localhost [127.0.0.1]) by turbine.trit.org (Postfix) with ESMTP id AAF433E1A; Fri, 23 Aug 2002 22:39:09 +0000 (UTC) To: Giorgos Keramidas Cc: current@freebsd.org Subject: Re: cvs commit: src/usr.bin/lock lock.1 lock.c In-Reply-To: <20020823044145.GA784@hades.hell.gr>; from keramida@ceid.upatras.gr on "Fri, 23 Aug 2002 07:41:45 +0300" Date: Fri, 23 Aug 2002 22:39:09 +0000 From: Dima Dorfman Message-Id: <20020823223909.AAF433E1A@turbine.trit.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Giorgos Keramidas wrote: > charon@hades[07:37]/home/charon$ lock -v -p > the virtual terminal locks, but since my current tty is a pty of > screen(1) I can't type anything. Now, before anyone hits me with a > heavy, blunt thing... I know this isn't supposed to work. The > evilness happens when I hit CTRL-ALT-ESC though. There's somewhere a > nasty interaction of DDB and the locked consoles. The system freezes Not quite; it's just constantly trying to switch the console. Type "c" (for continue) and press enter to "unfreeze". > and a constant beeping sound can be heard form the PC speaker :-( This happens regardless of whether you're using screen(1) or not; doing a "lock -v" and breaking into DDB is sufficient to reproduce the problem (actually, I seem to remember testing this combination when I originally wrote the patches, and it seemed to work "okay", but I can reproduce it just fine now on a -stable box (I merged this stuff locally in preparation to MFC)). It's easy enough for syscons to allow the switch when it's requested by the kernel, but what do we do when we get out of DDB? We don't keep track of which console we came from, so we can't switch back to that (I suppose this can be changed). If we keep the switch lock, the user no longer has access to the instance of "lock(1)" that's maintaining it; if we don't keep the lock, well, the console isn't locked anymore. I think the latter might be the best and easiest choice, but it's counter-intuitive. I'm not terribly concerned with the security implications in this case; if you can get into DDB, you can cancel the lock, anyway; the only harm in not keeping the lock is breaking POLA. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message