home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v5 / text0020.txt < prev    next >
Encoding:
Text File  |  1987-06-30  |  3.3 KB  |  62 lines
  1. >From: pyramid!sun!guy@sally.UTEXAS.EDU (Guy Harris)
  2. Date: Wed, 22 Jan 86 22:02:59 PST
  3.  
  4. > Objections to keeping TZ as a UNIX environment object can be
  5. > answered by putting the timezone information (to whatever
  6. > degree of precision is necessary) in the per-process context
  7. > maintained by UNIX, also called the `u.' area. ...
  8. > 
  9. > The umask(2) syscall provides a precedent for carrying
  10. > special OS-related information in the per-process context
  11. > maintained by the kernel.  I'm tempted to propose that TERM
  12. > information should be kept there too.
  13.  
  14. This dates back to PWB/UNIX; they wanted to store some per-process
  15. information (namely, the login name, since PWB/UNIX was originally V6-based
  16. and, given a limit of 256 user IDs, required several people to share a user
  17. ID) and they did so in the u-area.  However, when PWB became V7ized, they
  18. stored it - in the environment.
  19.  
  20. What benefits accrue from storing this information (timezone or terminal
  21. type) in the u-area instead of in the environment?  This proposal implies
  22. that the information isn't protected, since there would be system calls to
  23. change it, so that's not one of the benefits.  (It has been argued that
  24. terminal type information should be stored with the *terminal*, and not with
  25. the process, so it's not clear that the u-area *or* the environment is the
  26. proper place for this.)  The reason the umask was stored in the u-area is
  27. probably so that programs didn't have to change to be affected by the umask;
  28. in order for it to work with "open", it had to be accessible to the kernel,
  29. and the most logical place for variables like that is the u-area.
  30.  
  31. The main objections I've seen to storing the time zone in the environment
  32. are that it is subject to forgery and that there's no way to set TZ for
  33. *every* process on the system (and even for those processes where you *can*
  34. set it, current S3/S5 requires you to set it independently in several
  35. places).  If the time zone information is moved from the user-mode
  36. per-process data segment to the kernel-mode per-process data segment, this
  37. doesn't solve the problem of forgery unless the system call to set it is
  38. privileged (in which case it isn't really settable by most processes, so why
  39. is it a per-user item?) and doesn't solve the problem of setting it
  40. initially.
  41.  
  42. The best solution to both of those problems I originally saw in an article
  43. about mixing V7 and S3 compatibility in Xenix.  Microsoft kept the old V7
  44. "ftime" call, which gets the time zone information from the kernel (which is
  45. set at system build time, or if you have something like an EEPROM on your
  46. machine it can be set at boot time; there is no unprivileged system call to
  47. set it, so it's unforgeable), and had "ctime" fetch the time zone
  48. information from the kernel if there was no TZ environment variable.
  49.  
  50. This solves the problem of setting it initially, as the default setting is
  51. what most programs would want to use; if a user dials in from another time
  52. zone, the program they run as their shell will have to provide some way for
  53. them to set TZ.  It also solves the problem of forgery, assuming the S5
  54. "putenv" function is present.  Have "ctime" (or anybody else) use the
  55. kernel's timezone value if TZ is present but has a null string as a value,
  56. and have programs that want to be guaranteed to get the "official" time zone,
  57. like "uucico", just do 'putenv("TZ=");' and wipe out the supplied time zone.
  58.  
  59. Volume-Number: Volume 5, Number 21
  60.  
  61.  
  62.