From owner-freebsd-current@FreeBSD.ORG Fri Jan 7 11:22:12 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 5E1DB106564A; Fri, 7 Jan 2011 11:22:12 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 824B08FC15; Fri, 7 Jan 2011 11:22:11 +0000 (UTC) Received: by bwz12 with SMTP id 12so9869247bwz.13 for ; Fri, 07 Jan 2011 03:22:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:reply-to:x-mailer:mime-version :content-type:content-transfer-encoding; bh=r32os0l9rx6/nB/aH5jdnAgHarILibTzxrf6YrQyDA0=; b=qz90YEbai6RkHcnwi6j2+JghQEbjHLTFJAysapquBKBHqjHOKcCKi0cxeh2cghh3Ji HmABAl7d8FlBYHzXMSVv+nQps+C0wu8Y4i0DQVK097CCv2VkuK/d5cjENA2u/vK+0rtB FwALbWHtfinMrOof6fShqI4RYG45OXssVXYdc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=dOq/NXZqE9sUi7D/N7fEdZeZ8adZNOw6n718Aa0NRwnk5XdNahmtxaaC5gWhaECvCX Oa02EkmSFJ4wJY/nYsslt2Ybxt/rStcNwTwLQkKtitkEb8/pdgVnbNH1taeI1UGo/omg 7Ne33epjRIjarq9IXp9kywg42XIGSXZdyc/CA= Received: by 10.204.64.208 with SMTP id f16mr2601265bki.61.1294397590972; Fri, 07 Jan 2011 02:53:10 -0800 (PST) Received: from ernst.jennejohn.org (p578E194D.dip.t-dialin.net [87.142.25.77]) by mx.google.com with ESMTPS id v1sm13967356bkt.5.2011.01.07.02.53.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 02:53:09 -0800 (PST) Date: Fri, 7 Jan 2011 11:53:06 +0100 From: Gary Jennejohn To: Garrett Cooper Message-ID: <20110107115306.2bfd15d8@ernst.jennejohn.org> In-Reply-To: References: <4D268557.2090704@ee.lbl.gov> <4D268B98.3080906@ee.lbl.gov> <4D269B72.4040709@ee.lbl.gov> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: FreeBSD Current , Ed Schouten , Craig Leres 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: gljennjohn@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 11:22:12 -0000 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. -- Gary Jennejohn