Security

  As discussed in Section 2.4, the Topaz security model differs significantly from that of Ultrix; luckily this has little or no impact on most application programs.

  Internally, Taos associates user names rather than user identifiers with files and processes. However, it translates between names and identifiers as necessary at the kernel-call interface (e.g., the stat kernel call).

  As described in Section 2.4, page , Taos always uses the real user name and password for validating access to remote files; it uses the effective user name for validating access to local files and for all other local operations. If the execve kernel call is given the path name of a remote file, it ignores the setuid bit. (In the future, Taos will allow `trusted' servers to provide setuid programs.)

      Taos does not implement the notion of the real and effective group identifiers of a process. The getgid and getegid kernel calls always return 0, and the setregid kernel call is a no-op.

    Taos implements the group access list of a process in a different way than Ultrix. The setgroups kernel call is a no-op; instead Taos determines group membership by looking up the current effective and real user names in a database stored in the Interim Name Service. The getgroups kernel call always raises SIGSYS; the Interim Name Service querying facilities can be used instead. (See ns(8).)

  Taos implements the setreuid kernel call by translating the user identifiers to user names and then calling OSFriends.SetMyUser (see page .) (The Taos implementation of setreuid also accepts an optional third argument: a character pointer specifying a password to pass to SetMyUser.)

  Taos implements the access kernel call differently than Ultrix does. The Ultrix implementation of access uses the real user where other kernel calls would use the effective user; apparently the access kernel call was originally intended to allow a program running as effective user root to check whether the user who invoked it is allowed to access a specified path name with a specified mode. However, many programs (e.g., emacs and csh) invoke the access kernel call assuming that real = effective, and don't work correctly when that assumption is false. For example, the enable command runs a program with effective = root and real = you. Therefore the Taos implementation of access always uses the effective user. This change may break certain setuid programs, but we haven't encountered any yet.

      The Ultrix login and su commands won't work on Taos; see instead the Taos login and enable commands.