Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 07 Jan 2011 12:23:52 +0100
From:      Claude Buisson <clbuisson@orange.fr>
To:        Garrett Cooper <gcooper@FreeBSD.org>
Cc:        FreeBSD Current <freebsd-current@freebsd.org>, Ed Schouten <ed@freebsd.org>, Craig Leres <leres@ee.lbl.gov>
Subject:   Re: xterm -C and TIOCCONS vs. PRIV_TTY_CONSOLE
Message-ID:  <4D26F7C8.2010508@orange.fr>
In-Reply-To: <AANLkTi=gHW=ShE_p=LPj-k1FC1e2-SpAWxyAsD=2MF7o@mail.gmail.com>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
On 01/07/2011 06:09, Garrett Cooper 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.
> Cheers, a
> -Garrett
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
>

This is not a new problem, as it lead to a thread on hackers@ in November 2008
(search for "[Testers wanted] /dev/console cleanups" and "xconsole").

I tried a "proof of concept" by building a kernel with options MAC, and patching
mac_stub.c to have stub_priv_grant() return 0 in stade of EPERM for
PRIV_TTY_CONSOLE.

With this, the kernel messages are displayed in xconsole, but not the others
messages sent with syslog.

Of course, this hack is not to be used on a production system.

I hope that a true solution will be found one day or another.

Claude Buisson.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D26F7C8.2010508>