Date: Fri, 25 Feb 2011 15:48:44 -0800 From: YongHyeon PYUN <pyunyh@gmail.com> To: Gary Jennejohn <gljennjohn@googlemail.com> Cc: FreeBSD Current <freebsd-current@freebsd.org>, Ed Schouten <ed@freebsd.org>, Craig Leres <leres@ee.lbl.gov>, Garrett Cooper <gcooper@freebsd.org> Subject: Re: xterm -C and TIOCCONS vs. PRIV_TTY_CONSOLE Message-ID: <20110225234844.GA1485@michelle.cdnetworks.com> In-Reply-To: <20110107115306.2bfd15d8@ernst.jennejohn.org> References: <4D268557.2090704@ee.lbl.gov> <AANLkTinWu9-ZP_D0ShfvAtDpbuRPWa81hLb3hw=OQoxX@mail.gmail.com> <4D268B98.3080906@ee.lbl.gov> <AANLkTinEG7SJ80Ljrecg%2Bq_TOGy8bicKVUPZRRpzieV%2B@mail.gmail.com> <4D269B72.4040709@ee.lbl.gov> <AANLkTi=gHW=ShE_p=LPj-k1FC1e2-SpAWxyAsD=2MF7o@mail.gmail.com> <20110107115306.2bfd15d8@ernst.jennejohn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 07, 2011 at 11:53:06AM +0100, Gary Jennejohn wrote:
> On Thu, 6 Jan 2011 21:09:05 -0800
> Garrett Cooper <gcooper@FreeBSD.org> wrote:
>
> > On Thu, Jan 6, 2011 at 8:49 PM, Craig Leres <leres@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.
>
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. :-(
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110225234844.GA1485>