xterm -C and TIOCCONS vs. PRIV_TTY_CONSOLE

[Gary Jennejohn]

On Thu, 6 Jan 2011 21:09:05 -0800
Garrett Cooper <gcooper at FreeBSD.org> wrote:

> On Thu, Jan 6, 2011 at 8:49 PM, Craig Leres <leres at ee.lbl.gov> 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