layers and utmp

[gwyn at brl-smoke.UUCP]

In article <11967 at sun.uucp> guy%gorodish at Sun.COM (Guy Harris) writes:
>This is a depressingly common source of grief in UNIX.  The Sun
>window system puts entries in "utmp" every time it opens up a
>terminal emulation window, just so that programs using that terminal
>emulator as their terminal don't get confused.

One problem is that /etc/utmp can normally be written only by privileged
processes.  Should multi-window EMACSes (on ordinary systems, not Suns),
for example, run privileged just so they can alter /etc/utmp?  I should
think not.  What would be best would be a "terminal resource manager",
at least for ptys/xts, that would perform the /etc/utmp update as a
side-effect of allocating ptys.  By the way, I got enough complaints from
users about the number of entries for each user in /etc/utmp (we use a lot
of 5620 DMDs) that I eventually had to re-think the issue; the default
behavior of our current "mpx" ("layers" replacement) is to maintain just
one layer entry per user, for what is deemed their "communication layer"
(the one running sysmon, for example); the most obvious consequence of
this is that "write whoever" has well-defined, controlled behavior (it is
NOT NICE for it to blather into an inappropriate layer).  Of course,
deletion of the layer causes the utmp entry to move, and the original tty
port entry reappears when a user exits layers.  I think AT&T's "relogin"
utility could be adapted to do the actual /etc/utmp updates, which would
be a good design approach from the security standpoint, but I haven't
really studied that yet.

I should note that there is a lot of 4.3BSD user-mode code that does
NOT follow the advice contained in the UNIX Reference Manual about
the proper way to determine user names.  (It's really great to get
"talk" messages from people named "" or "???".)  I fixed almost all
cases of this in our 4.2BSD systems but our 4.3BSD converters lost the
fixes.  People, just because a process has a controlling terminal does
NOT mean that there is a corresponding /etc/utmp entry, especially in
the world of 4BSD ptys!  Read GETLOGIN(3) in the Manual (if it's a
4.2BSD manual, first fix the typo: "getpw" should be "getpwuid") then
follow the recommended procedure in order to determine a login name
to associate with the process.

The root problem is that /etc/utmp's function was designed with a
restricted model of "users" and "terminals".  The original model is
no longer appropriate, and therefore neither is /etc/utmp, although
we're stuck with it for the time being.  There is no "right" way to
handle /etc/utmp in the world of windows/layers, although there are
some clearly wrong ones.  A revised user<->terminal mapping database
design should be part of any future (pseudo-)terminal resource manager.

----------

In case people haven't yet noticed, AT&T UNIX System V Release 3 now
includes "layers" as a standard part of the system, packaged as
"Windowing Utilities".  ATTIS (former Teletype) has at least three
terminals that support layers operation, shown at UniForum, from one
that has text only (model 615) through a dot-mapped model (620) with
builtin GKS and Tek4014 support to the 5620 DMD (dot-mapped display).
Given the adoption of layers as a standard part of (real) UNIX, I
expect AT&T will continue this trend.  I wonder if other terminal
vendors will join in?  (Clearly Sun, for one, is taking a different
approach to windows; each approach has its own merits.)