II14235: TWS Z/OS E2E SERVER TASK MUST NOT RUN AS UID0 (ROOT, UID=0, UID(0)) DUE TO POSSIBLE PROBLEMS

APAR status

• Closed as canceled.

Error description

• APAR PK34310 changes the documentation in the TWS z/OS
  Installation Guide and Scheduling End-to-end manuals, and also
  the comments associated with the EQQPCS05 installation job,
  to specify that the E2E server should not run as UID(0).
  The purpose of this INFO APAR is to document several reasons
  why the use of UID(0) causes problems with the E2E server, and
  also to explain how to convert the eqqUID (E2E server id) from
  UID=0 to a non-zero value (the non-zero value should also be
  unique).
  
  Reasons why UID0 is not recommended for the E2E server:
  
  (1) As documented in the z/OS UNIX System Services Programming:
      Assembler Callable Services Reference manual, there are
      several commands which can be problematic if used from a
      root or UID0 id.  These include getpwuid  and w_getpsent.
      For getpwuid, it is documented that:
      "It is impossible to predict which userid will be returned
      on a call to getpwuid with a UID=0"
      For w_getpsent, it is documented that:
      "Only those processes are returned for which RACF allows the
      user access based on its EUid, RUid, or SUid."  For UID=0
      this means all processes would be included.
  
  (2) In the z/OS UNIX System Services Planning manual, section
       "Assigning a UID of 0", it is documented that "you risk
       entering commands that can damage the file system"if
       UID0 is used, and also that "Assignment of UID(0) should
       be limited to the user associated with started procedures
       such as the OMVS kernel and the user who installs the
       ServerPac. It should be avoided for the user IDs belonging
       to the real users whenever possible."
  
  (3) Security problems can occur due to getpwuid command failing-
      PK01415 attempts to address this by checking for userids
      whose default group (DFLTGRP) does not have an OMVS segment
  
  (4) An E2E server task running as UID=0 can initialize before
      OMVS has fully initialized (BPXI004I message). This causes
      a problem that is difficult to diagnose.  When a non-root id
      is used, the server task will wait for OMVS to be
      initialized. Message "BPXP022E ONE OR MORE JOBS ARE WAITING
      FOR UNIX SYSTEM SERVICES AVAILABILITY" is issued in this
      case.
  
  (5) The AWSEDW026E problem (documented in INFO APAR II14187)
      can occur if UID0 is used. This causes an outage in the E2E
      server task.
  
  (6) There is a potential for Language Environment (LE) abends
      4039 or 4042 if UID0 is used for the E2E server.  See APAR
      PK34716 for details.Note that the reason PK34716 is only
      applicable if UID(0) is used is that the TWS code issues
      the w_getpsent command but does NOT use any command lines
      in excess of 1023 characters.  Therefore PK34716 can only
      be applicable for TWS if some other application has a
      process which uses a command line > 1023 characters- and
      the TWS code will ONLY check the process for some other
      application if it is running as UID0.
  
  If additional problems are found with UID0 and the TWS E2E
  server task, they will be documented in this INFO APAR
  
  Converting from UID0 to non-UID0 for the E2E server task.
  .
  If the E2E server task is currently running as UID0, the
  following steps are needed to change this to a non-UID0 id
  (1) Orderly shutdown of the E2E environment (see shutdown
      procedure below)
  (2) Delete the existing WRKDIR and rerun EQQPCS05 with non-UID0
      value for eqqUID
  (3) Change the userid associated with the E2E server task
  (4) Restart the controller and E2E server task
  
  Shutdown procedure:
  In order to shutdown the E2E environment to avoid any loss of
  data when the work directory (WRKDIR) is reinitialized, the
  following procedure should be used:
  
   A.  Deactivate TWS job submission from TWS dialog (option 9.1
  then FY option)
  
   B.  Wait for TWSOU to empty  (see technote 1145019 )
   C.  Stop the Server task
   D.  Wait for TWSIN to empty  (see technote 1145019)
   E.  Stop the Controller task
  
  Technote 1145019 is available at this URL:
  http://www-1.ibm.com/support/docview.wss?uid=swg21145019
  
  Once the shutdown has been performed, the existing WRKDIR
  should be deleted ( rm -r /WRKDIR ) and then the EQQPCS05
  job run with eqqUID in the STDENV specified as a unique,
  non-UID0 userid (A new userid could be defined for this purpose
  if necessary).
  
  Once the new WRKDIR is defined, change your security product
  to specify that the E2E server task should be started under
  the id you specified as eqqUID in the EQQPCS05 job.
  For example, with RACF, the following could be used to change
  the server task (O82S) from running as id ROOT to running as
  id UID100:
   RALTER  STARTED O82S.* -
           STDATA(USER(UID100) GROUP(OPC) TRUSTED(NO))
   SETROPTS RACLIST(STARTED) REFRESH
   SETROPTS GENERIC(STARTED) REFRESH
  
  Once the security change is made, the controller should be
  started, which will in turn start the E2E server task.
  If  FTWJSUB(NO) is specified in the controller JTOPTS, then it
  will be necessary to restart FTA job submission from option 9.2
  of the TWS dialog.
  

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

• INFOPALIB 5697WSZ01 E2E PK34310
  

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels