From owner-freebsd-current@FreeBSD.ORG  Sun Apr 25 10:28:14 2004
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
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 6D70C16A4CF
	for <freebsd-current@FreeBSD.org>;
	Sun, 25 Apr 2004 10:28:14 -0700 (PDT)
Received: from ran.psg.com (ip166.usw253.dsl-acs2.sea.iinet.com
	[209.20.253.166])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 37FAB43D46
	for <freebsd-current@FreeBSD.org>;
	Sun, 25 Apr 2004 10:28:14 -0700 (PDT)	(envelope-from randy@psg.com)
Received: from localhost ([127.0.0.1] helo=ran.psg.com.psg.com)
	by ran.psg.com with esmtp (Exim 4.32; FreeBSD)
	id 1BHnQI-00010Y-R0; Sun, 25 Apr 2004 10:28:10 -0700
From: Randy Bush <randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16523.62762.329440.73697@ran.psg.com>
Date: Sun, 25 Apr 2004 10:28:10 -0700
To: Bruce Evans <bde@zeta.org.au>
References: <16523.38199.999917.660146@ran.psg.com>
	<20040425224147.H15264@gamplex.bde.org>
cc: FreeBSD Current <freebsd-current@FreeBSD.org>
Subject: Re: xterm -C not working
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 25 Apr 2004 17:28:14 -0000

>> xtem -C seems not to get console output on the xterm,
>> though, if i run in non-X, i do get console messages
>> ...
>> not sure this is related, but i noticed that the kernel
>> config
>>    options         UCONSOLE
>> is no longer legal (and the handbook on kernel configuration
>> forgot to remove it).
> 
> This option opened a security hole in the broken TIOCCONS ioctl.
> I think xterm -C uses this ioctl.  The security hole was that
> everyone was permitted to take over the console.  Now only users
> who can open /dev/console for reading can take it over.  The
> brokenness is that TIOCCONS causes panics.  It apparently never
> worked, but it causes panics more reliably now because the bad
> things that it does are detected by locking assertions.

hmmm.  and, considering the devfs stuff, when/how can/should one
allow the X server user to have read perms?

randy