Re: /etc/utmp

[ole!rwing!pat () nwnexus wa com (Pat Myrto)]

"In the previous message, ole!research.att.com!smb said..."
>        I guess I didn't make myself totally clear.  I said the fix was to make
>        utmp not world writtable (and I believe I mentioned a workaround using
>        a group (the tty group temporarily, since only staff types would be using
>        xterms on the given system).  But the fact remains Xterm really needs to be
>        SUID root so it can change perms and OWNERSHIP on its pty to the user.
>
> Let me suggest that you take a look at the SysV Release 4 pty mechanism.
> I'll be vain enough to claim partial credit for the design.  With it,

W/o a source license, that is a tad hard to do.  But in the case of the
system I am discussing - a Sun, the SysVr4 ptys are not available,
so its moot until I have to work on a SysVr4 box

> you don't need root to allocate a pty.  A single subroutine -- and a
> hidden setuid root program allocate the pty, change the ownership,
  ^^^^^^^^^^^^^^^^^^
The fact it is hidden doesn't mean it isn't there.  Whether its an
actual program or within the driver itself, the potential for problems
exist (but granted, one SUID program does beat the hell out of a dozen).

> set the modes -- and do it all without the usual race conditions
> that BSD-derived systems need root privileges, vhangup(), and assorted
> other misfeatures to bypass.
 
> It works like this.  The pty user opens a pty master (which, btw, is
> a clone device; no nonsense about looping through some fixed number
> of possible ptys).  The open file descriptor for the master end -- and
> that's not reopenable, and it won't be allocated unless the slave end
> is idle -- is passed to this setuid root program.  From the master
> fd, it determines the name of the corresponding slave device, and
> chowns and chmods it.  It then issues an ioctl unlocking it -- until
> that ioctl is issued, attempts to open the slave device will fail.
> Presto -- no race on open permissions.  I forget if the subroutine
> opens the slave end for the caller, or just passes back the name, but
> either way, the interface is much easier.  I also don't remember if
> utmp is handled by this routine, but the extension is obvious -- you
> pass around the master end fd, and a small trusted program does the
> appropriate diddles.

Sounds nice, I would like to see the implementation (the thumbnail sketch
is a tad bare, not a slam, just a statement of fact to fit in a msg).
One would think some of the ideas - making ptys unusable until allocated
- would be nice to use on BSD ptys.  Probably require futzing about in
those driver modules, meaning REPLACING them since the source isn't
available...  such is life not rolling in dough, I guess...  :-)

>        But since xterm was SUID root to accomplish this, and a bug in XTERM
>        made it possible to alter system files, Sun's apparant fix was to
>        make utmp world-writeable, all the pty's world-writeable, and remove
>        the SUID bit from Xterm.
>
> You've got the causality wrong.  Sun had a writable wtmp years ago,
> precisely to avoid making terminal emulators setuid root.  The bug --
> probably inevitable -- bit folks who used MIT's xterm, because MIT
> didn't see the danger.

I stand corrected.  Thanks for the bit of history.  But the writeable
utmp merely opens up another can of worms making little (and not so
little) holes to poke through...  Yeh, I am gonna recompile it from
sources, and take out that logging feature (which I never use anyway).
And try to see if there are other gotchas - hopefully one can simply
open and chown/chmod the pty, than give up the SUID status as early as
possible and not restore it until it exits, then only resume it long
enough to clean up the utmp entry.

Seems anything creating a file while running with root privs is
full of gotchas, especially with symlinks around.  There is supposed
to be a 'safefile' function in the mail command that if used properly
makes sure the file isn't a symlink or being switched under it, I
would like to see an example of how that is done and not being subject
to race conditions.

>        One could use a variation on that pty command available off
the net, >        it works fine, but, alas, *IT* has to run SUID root,
too in order >        to be able to chown the pty to the user...  > >
Something has to run setuid root, but it doesn't have to be a whale.

Unfortunately, it does have to be a whale, when one is limited to
working with what one has.  And one has to do that when one is operating
on the cheap...
-- 
pat@rwing  [If all fails, try:  rwing!pat () ole cdac com]  Pat Myrto - Seattle WA
"No one has the right to destroy another person's belief by demanding
empirical evidence."  --   Ann Landers, nationally syndicated advice columnist
and Director at Handgun Control Inc.