Re: [XonX-Users] Xterm SUID?

[Patrik M. <pa...@ch...>]

On 04-12-24 09.59, John Davidorff Pell (joh...@ma...) wrote:

> 
> On 23 Dec 2004, at 08:59, Torrey Lyons wrote:
> 
> 
>> At 7:08 PM -0800 12/22/04, John Davidorff Pell wrote:
>> 
>> 
>>> Hi!
>>> 
>>> I've got a few questions:
>>> 1) Why is Xterm SUID?
>> 
>> The short answer is so that it can chown the pseudo tty that it uses.
>> The long answer is that it does not absolutely need to do this and in
>> any case there are non-SUID ways to do this. Apple's X11 does not have
>> an SUID xterm and it just fails to chown the tty. The main symptom of
>> this is that if you use "who" you will not see your xterm sessions
>> listed. On the other hand if you open up a bunch of SUID xterm or
>> Terminal.app windows you will see them all listed in who. Terminal.app
>> is not SUID so there is clearly another way to do this. Most OS'es
>> have provided some non-SUID way to do this, but this is not standard.
>> If we knew how to do this on Mac OS X we could have xterm do this
>> instead.

Chowning the tty is not what makes terms show up to who. Who only reads out
the current users from /etc/utmp - which is 644 root, so xterm needs to be
root to write in it. Terminal doesn't write in utmp, so multiple Terminal
windows don't show up several times. Loginwindow (I think) writes in utmp
when you log in, so a graphical session shows up on who even if there are no
Terminal windows open. The same way sshd writes in utmp if you log in that
way. The logical thing would be to have XDM write in utmp - it's obviously
running as root anyway. Just launching X11 should not write in utmp - you're
not logging in again, you're just launching another process.

I don't know why xterm chowns the tty. There is probably a good historical
reason for it, but you can work without owning the tty today.

> Terminal.app launches /usr/bin/login, which is prolly the best thing to
> do, as it is something that must be SUID anyway, and so should handle
> all the things together that might require that. This has the
> unfortunate side-effect of launching the default login shell... oh,
> wait, that's what its supposed to do. ;-)

Are you sure that's what it does? I don't think Terminal.app does anything
that requires root access. I think it only launches the relevant shell as a
login shell - you don't get a login prompt when you open a Terminal window,
do you? 

If you check the archives for this list (should be at sourceforge, right?),
you will find an old discussion between Torrey, Greg Parker and yours truly.
The subject has been up before.
 
>>> 3) Shouldn't the default be not-SUID, and systems that require it
>>> explicitly set it to be SUID?
>> Perhaps, but since the Xserver is also SUID on many platforms it
>> sticks out less than as the only SUID X11 program on Mac OS X.
> SUID binaries are something that I have a pet-peeve about. I think that
> they should never be the default and, where required, are usually
> design-flaws.

What, you mean that xterm is not the perfect terminal? I'm shocked!

Really, xterm is very old. The source is hard to work with. Its one
redeeming feature is that it supports every terminal protocol since
cuniform, but that's a pretty big feature. Of course having a big userland
app like xterm suid is a big security risk, and I think everyone understands
that.

Note that rxvt is not suid root. If it were up to me, I'd make rxvt (or some
other modern terminal app) the new default xterm, modify XDM to write in the
user log (seems like the logical way to me - if you log in graphically to an
X11 terminal and use only shortcuts in the window manager to launch
programs, you don't write anything in utmp or even in wtmp, the user log)
and keep the old xterm as an optional install for those situations where you
need odd terminal protocols.

Alternatively, just determine the platforms where chowning the tty is
necessary and making it suid on those platforms only. Oh, and change the
default so it doesn't write into utmp - it can be done with a switch at
launch today.
-- 
Patrik Montgomery // pa...@ch...