Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbosgd!gatech!ut-sally!std-unix
From: std-unix@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: TZ and TERM per process
Message-ID: <4032@ut-sally.UUCP>
Date: Thu, 23-Jan-86 13:33:36 EST
Article-I.D.: ut-sally.4032
Posted: Thu Jan 23 13:33:36 1986
Date-Received: Fri, 24-Jan-86 22:06:46 EST
References: <4029@ut-sally.UUCP>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 59
Approved: jsq@sally.UUCP

From: pyramid!sun!guy@sally.UTEXAS.EDU (Guy Harris)
Date: Wed, 22 Jan 86 22:02:59 PST

> Objections to keeping TZ as a UNIX environment object can be
> answered by putting the timezone information (to whatever
> degree of precision is necessary) in the per-process context
> maintained by UNIX, also called the `u.' area. ...
> 
> The umask(2) syscall provides a precedent for carrying
> special OS-related information in the per-process context
> maintained by the kernel.  I'm tempted to propose that TERM
> information should be kept there too.

This dates back to PWB/UNIX; they wanted to store some per-process
information (namely, the login name, since PWB/UNIX was originally V6-based
and, given a limit of 256 user IDs, required several people to share a user
ID) and they did so in the u-area.  However, when PWB became V7ized, they
stored it - in the environment.

What benefits accrue from storing this information (timezone or terminal
type) in the u-area instead of in the environment?  This proposal implies
that the information isn't protected, since there would be system calls to
change it, so that's not one of the benefits.  (It has been argued that
terminal type information should be stored with the *terminal*, and not with
the process, so it's not clear that the u-area *or* the environment is the
proper place for this.)  The reason the umask was stored in the u-area is
probably so that programs didn't have to change to be affected by the umask;
in order for it to work with "open", it had to be accessible to the kernel,
and the most logical place for variables like that is the u-area.

The main objections I've seen to storing the time zone in the environment
are that it is subject to forgery and that there's no way to set TZ for
*every* process on the system (and even for those processes where you *can*
set it, current S3/S5 requires you to set it independently in several
places).  If the time zone information is moved from the user-mode
per-process data segment to the kernel-mode per-process data segment, this
doesn't solve the problem of forgery unless the system call to set it is
privileged (in which case it isn't really settable by most processes, so why
is it a per-user item?) and doesn't solve the problem of setting it
initially.

The best solution to both of those problems I originally saw in an article
about mixing V7 and S3 compatibility in Xenix.  Microsoft kept the old V7
"ftime" call, which gets the time zone information from the kernel (which is
set at system build time, or if you have something like an EEPROM on your
machine it can be set at boot time; there is no unprivileged system call to
set it, so it's unforgeable), and had "ctime" fetch the time zone
information from the kernel if there was no TZ environment variable.

This solves the problem of setting it initially, as the default setting is
what most programs would want to use; if a user dials in from another time
zone, the program they run as their shell will have to provide some way for
them to set TZ.  It also solves the problem of forgery, assuming the S5
"putenv" function is present.  Have "ctime" (or anybody else) use the
kernel's timezone value if TZ is present but has a null string as a value,
and have programs that want to be guaranteed to get the "official" time zone,
like "uucico", just do 'putenv("TZ=");' and wipe out the supplied time zone.

Volume-Number: Volume 5, Number 21