Re: /etc/utmp

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

> > 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

The SVR4 ptys work as simple as this (from Solaris 2.x pts(7)):

          int fdm fds;
          char *slavename;
          extern char *ptsname();

          fdm = open("/dev/ptmx", O_RDWR);   /* open master */
          grantpt(fdm);                      /* change permission ofslave */
          unlockpt(fdm);                     /* unlock slave */
          slavename = ptsname(fdm);          /* get name of slave */
          fds = open(slavename, O_RDWR);     /* open slave */
          ioctl(fds, I_PUSH, "ptem");        /* push ptem */
          ioctl(fds, I_PUSH, "ldterm");      /* push ldterm */

The function grandpt() calls /usr/lib/pt_chmod that does all
the chowning.  Note that until one calls unlockpt (on the master),
one can't open the slave.  

> > 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).

Let's phrase it: a dozen small set-uid programs is better than
one big set-uid program.  pt_chmod is tiny: it's about 10 lines
of actual code.


> 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...  :-)

I believe Sun's tty jumbo patch does just that with the BSD ptys.

> 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.

Exactly.  Unfortunately, not all systems can totally give up root's
uid during execution.  Even the old BSD setreuid() is not powerful
enough to do this.  Only saved ids get you there.
(The root uid should only linger as saved uid when it's not needed,
the effective and real uid should be the invoking user's uid.)

Note that you should be careful when giving up user ids.  If you think that
it's safe to open the {u,w}tmp{,x} files and then revoke the root user-id
for ever and use the file descriptors, you're sadly mistaken.
As soon as you give up all the roto powers for ever, the user can
attach to the program with a debugger and capture the filedescriptors you
have opened (or any other capability the program has that it needed
it's root privs for to get and that can be reused in devious ways)

> 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.

The mail command doesn't run as root, it runs as the receiving user.
This still gives a lot of problems, unless you can make sure
that every users mailbox exists or exists under his/her own home directory.
Set-uid root programs should never create files as root, unless these
files are in a root-only writable directory.

Casper