From owner-freebsd-current@FreeBSD.ORG Sat Feb 26 00:10:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C52551065670; Sat, 26 Feb 2011 00:10:37 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 65C918FC0C; Sat, 26 Feb 2011 00:10:37 +0000 (UTC) Received: by iyj12 with SMTP id 12so1530685iyj.13 for ; Fri, 25 Feb 2011 16:10:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:date:to:cc:subject:message-id:reply-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=ERsXC5plJ00+qEb3HnWGOa8y1adLwxit6b9P6R/lY/8=; b=iXyFklv7rewL6kes1/D8z9WB59qHSaydKRznz/MQo9kJAZv2jLvEUmgshaFUvzGqAP i1m8VE3im+1Qdpw9CIwTK68kgYrFX8dqGeTuVqpS8gJwc6/00aXQUMxTXCAqiWp2/pOC D1s+YwUmFaOyopYY1X2y3mY4GZjXzi5RW7VCA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=K3qM3RaXjcU12ljquPeSqeVtoE0dBIciZKBHftXNToc68xSnfY5qZzPm7F0qJ1uV0s z3kcjuvJ7/dchQ59ZRzH8G927EJpIR236m27bp7wMSEd/cpEi3gMFcpCJPLuM+74KVXd SogJ0XJDRk77iP1rdWa+Yz+9R/R7L6/GDfN0Y= Received: by 10.42.164.201 with SMTP id h9mr1497510icy.108.1298677728478; Fri, 25 Feb 2011 15:48:48 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id xa8sm830005icb.22.2011.02.25.15.48.42 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 25 Feb 2011 15:48:44 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 25 Feb 2011 15:48:44 -0800 From: YongHyeon PYUN Date: Fri, 25 Feb 2011 15:48:44 -0800 To: Gary Jennejohn Message-ID: <20110225234844.GA1485@michelle.cdnetworks.com> References: <4D268557.2090704@ee.lbl.gov> <4D268B98.3080906@ee.lbl.gov> <4D269B72.4040709@ee.lbl.gov> <20110107115306.2bfd15d8@ernst.jennejohn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110107115306.2bfd15d8@ernst.jennejohn.org> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Current , Ed Schouten , Craig Leres , Garrett Cooper Subject: Re: xterm -C and TIOCCONS vs. PRIV_TTY_CONSOLE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 00:10:38 -0000 On Fri, Jan 07, 2011 at 11:53:06AM +0100, Gary Jennejohn wrote: > On Thu, 6 Jan 2011 21:09:05 -0800 > Garrett Cooper wrote: > > > On Thu, Jan 6, 2011 at 8:49 PM, Craig Leres wrote: > > > On 01/06/11 20:05, Garrett Cooper wrote: > > >> Just to make sure we're both on the same page: > > >> > > >> $ grep xterm /etc/ttys > > >> ttyv0 "/usr/libexec/getty Pc" ? ? ? ? xterm ? on ?secure > > >> ttyv1 "/usr/libexec/getty Pc" ? ? ? ? xterm ? on ?secure > > >> ttyv2 "/usr/libexec/getty Pc" ? ? ? ? xterm ? on ?secure > > >> ttyv3 "/usr/libexec/getty Pc" ? ? ? ? xterm ? on ?secure > > >> ttyv4 "/usr/libexec/getty Pc" ? ? ? ? xterm ? on ?secure > > >> ttyv5 "/usr/libexec/getty Pc" ? ? ? ? xterm ? on ?secure > > >> ttyv6 "/usr/libexec/getty Pc" ? ? ? ? xterm ? on ?secure > > >> ttyv7 "/usr/libexec/getty Pc" ? ? ? ? xterm ? on ?secure > > >> ttyv8 "/usr/local/bin/xdm -nodaemon" ?xterm ? off secure > > > > > > No, that's not what mine looks like. I changed it to match and rebooted > > > but it doesn't help with the TIOCCONS issue. > > > > > > When I run xinit, it starts up the xterm -C which does a TIOCCONS. The > > > 8.1 kernel checks for PRIV_TTY_CONSOLE which isn't set and denies the > > > request: > > > > > > ? ? ? ?case TIOCCONS: > > > ? ? ? ? ? ? ? ?/* Set terminal as console TTY. */ > > > ? ? ? ? ? ? ? ?if (*(int *)data) { > > > ? ? ? ? ? ? ? ? ? ? ? ?error = priv_check(td, PRIV_TTY_CONSOLE); > > > ? ? ? ? ? ? ? ? ? ? ? ?if (error) > > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?return (error); > > > > > > ? ? ? ? ? ? ? ? ? ? ? ?/* > > > ? ? ? ? ? ? ? ? ? ? ? ? * XXX: constty should really need to be locked! > > > ? ? ? ? ? ? ? ? ? ? ? ? * XXX: allow disconnected constty's to be stolen! > > > ? ? ? ? ? ? ? ? ? ? ? ? */ > > > > > > ? ? ? ? ? ? ? ? ? ? ? ?if (constty == tp) > > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?return (0); > > > ? ? ? ? ? ? ? ? ? ? ? ?if (constty != NULL) > > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?return (EBUSY); > > > > > > ? ? ? ? ? ? ? ? ? ? ? ?tty_unlock(tp); > > > ? ? ? ? ? ? ? ? ? ? ? ?constty_set(tp); > > > ? ? ? ? ? ? ? ? ? ? ? ?tty_lock(tp); > > > ? ? ? ? ? ? ? ?} else if (constty == tp) { > > > ? ? ? ? ? ? ? ? ? ? ? ?constty_clear(); > > > ? ? ? ? ? ? ? ?} > > > ? ? ? ? ? ? ? ?return (0); > > > > > > > > > There's nothing I see in all of /usr/src that turns on PRIV_TTY_CONSOLE > > > in any case. You could rewrite the above like this: > > > > > > ? ? ? ?case TIOCCONS: > > > ? ? ? ? ? ? ? ?/* Set terminal as console TTY. */ > > > ? ? ? ? ? ? ? ?if (*(int *)data) { > > > ? ? ? ? ? ? ? ? ? ? ? ?return (EPERM) > > > ? ? ? ? ? ? ? ?} else if (constty == tp) { > > > ? ? ? ? ? ? ? ? ? ? ? ?constty_clear(); > > > ? ? ? ? ? ? ? ?} > > > ? ? ? ? ? ? ? ?return (0); > > > > > > and it won't change any behavior. > > > > Ok -- figured I would ask about the obvious. I wish I could help > > you further right now, but unfortunately I have a lot on my plate. > > I've CCed ed@ and the list again so that someone else might be able to > > chime in and help you further. > > > > I'd say there are a few factors which come into play here: > 1) the setting of security.bsd.suser_enabled, default 1 > 2) kern_tty.c checking for a cred which is never set > 3) whether xterm is setuid root > > a) suser_enabled is almost guaranteed to be 1 on OP's system since just > about nothing works when it is set to 0 (tried that) > b) the kernel checking for the cred PRIV_TTY_CONSOLE is probably a bug > since it never gets set anywhere. However, this usually isn't noticed > because > c) xterm is generally setuid root and the logic in priv_check_cred() in > kern_priv.c doesn't even look at what cred is set to, except for a few > which can raise some limits, because cr_uid is 0 (super user) > > So, the crux of the matter is whether OP's xterm is setuid root. My > xterm is and I can run 'xterm -C' without a problem. > It seems I'm seeing this one on 8.2R. Of course, xterm is setuid root. I hacked tty.c to return success for TIOCCONS so was able to see kernel messages but messages passed through syslog still does not work. :-(