Re: pt_chmod

[casper () fwi uva nl (Casper Dik)]

> Going purely by the truss output (what little there is), it appears
> that pt_chmod does something approximately like this: 
> main(int argc, char **argv)
> {
>       chown(ptsname(atoi(argv[1])), getuid(), getgid());
> }

Yes, that's the almost exact call.  It's also followed by a chmod.

> I think Solaris has an unmapped page zero, which will cause a core
> dump.  If not, then it's probably the SVR4 case.

chown returns EFAULT, system calls don't get segmentation
faults.  (And set-uid programs don't dump core).

> Hmm. something else I though of too.  Imagine:  root is logged in on
> /dev/pts/34, and has the tty set to mode 0622.  Guess what this would
> do if you were a normal user: /usr/lib/pt_chmod 1 > /dev/pts/34
> You could then TIOCSTI to your hearts content.

No.  The file descriptor argument passed to ptsname() is the fd
that points to the *master* side of the pseudo terminal.  This master
side has no associated device node because it's opened through
a clone device.  Getting a file descriptor of a tty master of a tty that
is in use is impossible.  (open of /dev/ptmx will never return it)

You also cannot TIOCSTI to a terminal you own.  You can only TIOCSTI if
you're in the same process group as the terminal.  It is impossible to
get in the same process group of a terminal, even if you own it.
You might be able change the process group of the terminal though.

> A plea to OS programmers: 
> *dont* use "chown" on the result of the ptsname() - use fchown() - the
> user might have passed a fd in that's from a network mounted partition in
> an attempt to change the ownership of the local alias of the device.
> Also, RFS makes things interesting too, as the ioctl() in ptsname() is
> evaluated on the remote machine and returned back.

They can't use fchown.  The filedescriptor passed is not the file descriptor
of the pty.  There is no filedescriptor of the pty oin existance at that
point.  The error return of ptsname() should be checked though.

The tty open routines in SVR4 work like this:

        int fdm = open("/dev/ptmx", O_RDWR);
        char *slave;
        int fds;

        grantpt(fdm);  /* this one calls pt_chmod with fdm as first argument */
        unlockpt(fdm); /* after this you can open the pts */
        slave = ptsname(fdm); /* same as called by pt_chmod */
        fds = open(slave, O_RDWR);
        /* etc */

> Imagine this: 

N/A.

> /*
> Copyright (C) 1994, Peter Wemm. All rights reserved.


This code won't work for reasons outlined above.

Casper