Started task in z/OS lacks RACF privileges

I wish to test a JDBC server implementation running under z/OS. The usual approach would be to define a JCL procedure and run this as a started task. The started task requires a user ID under which it would run. The JDBC jars are placed in a ZFS file system which has been mounted in OMVS.

The user for the started task requires certain RACF privileges This was provided with the following JCL

//RUNRACF  EXEC PGM=IKJEFT01
//SYSUADS  DD DSN=SYS1.UADS,DISP=SHR
//SYSLBC   DD DSN=SYS1.BRODCAST,DISP=SHR
//SYSTSPRT DD SYSOUT=*
//SYSTSIN  DD *
AU JDBCUSR NAME('JDBC STC USER') PASSWORD(JDBCUSR) -
    OWNER(IBMUSER) DFLTGRP(STCGROUP) -
    UACC(READ)  OMVS(HOME(/u/zfs4svr) PROGRAM(/bin/sh) UID(3005) -
FILEPROCMAX(131072))

RDEFINE STARTED SVRPROC.** STDATA(USER(JDBCUSR) GROUP(STCGROUP) -
TRUSTED(NO))

SETROPTS CLASSACT(STARTED)
SETROPTS RACLIST(STARTED) REFRESH

PERMIT BPX.SERVER ACCESS(READ) CLASS(FACILITY) -
  ID(JDBCUSR)

SETROPTS CLASSACT(FACILITY)
SETROPTS RACLIST(FACILITY) REFRESH

When I start the task the following error message turns up in SYSOUT:

JVMJZBL1001N JZOS batch Launcher Version: 2.4.4 2013-05-07
JVMJZBL1002N (C) Авторские права IBM Corp. 2005, 2012
JVMJZBL1009E Дочерний процесс оболочки завершился без среды печати; // STDENV не должен содержать 'exit' JVMJZBL1042E Пакетный запуск JZOS failed, return code=101

After looking this up and reading what the IBM support documentation had to say, I and my colleagues were pretty confused. I then tried starting the server as a straight forward job. The user for the job had system administrator privileges. This works and we can test the JDBC server. Trying to run the job with the user for the procedure results in the same error as shown above.

It's obvious that JDBCUSR lacks some privilege or other. To run the server as a started task I need to know what privileges are lacking. We certainly don't wish to give the started task user system admin rights.

Is there some way to find out what is missing? This is very frustrating.

Edit 11.10.2016

The following JCL is the JOB that does work when has system admin privileges:

//V4JSRV   JOB USER=<user>,PASSWORD=<password>,REGION=200M
//*
//*******************************************************************
//* Call the server as a job
//*******************************************************************
//PROCS    JCLLIB ORDER=(ACHIM.JDBCSRV.CNTL)
//SRV      EXEC PROC=SRVPROC
//STDENV   DD DISP=SHR,DSN=ACHIM.JDBCSRV.CNTL(SRVENV)
//STRCTREP DD DISP=SHR,DSN=ACHIM.JDBCSRV.STRCTREP

The procedure looks like this:

//JDBCPROC  PROC JAVACLS='de.ubs.du.jdbcserver.Server',
//   ARGS='-p 5431 LOG-LEVEL=FINE',
//   LEPARM='',
//   LOGLVL='+T'
//JAVAJVM  EXEC PGM=JVMLDM70,REGION=200M,
//   PARM='&LEPARM/&LOGLVL &JAVACLS &ARGS'
//*JDBCPROC  PROC
//*JAVAJVM  EXEC PGM=JVMLDM70,REGION=200M,
//*   PARM='de.ubs.du.jdbcserver.Server -p 5431 LOG-LEVEL=FINE'
//STEPLIB  DD DSN=JVA700.SIEALNKE,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSOUT   DD SYSOUT=*
//STDOUT   DD SYSOUT=*
//STDERR   DD SYSOUT=*
//CEEDUMP  DD SYSOUT=*
//ABNLIGNR DD DUMMY

As you can see the job does nothing more than run the procedure. When is the username for the started procedure, the error above is produced, when it's an admin user, then the job runs normally. Obviously, to start it as a started task, the proc is copied to a public proc library (USER.PROCLIB to be precise).

There' nothing especially spectacular about any of this. In fact it is pretty banal. This is why we suspect that it's a RACF problem.

Edit (2) 11.10.2016

It's not a solution as yet, but I have managed to localize the problem. The started procedure functions if it is assigned the TRUSTED attribute. This effectively means the started task is treated as a "super user" in z/OS Unix (in other words it has root privileges). So now it is a matter of determining just what our server needs, that to date is only available when run by a super user. When I find out, I'll post a solution.

Edit (3) 12.12.2016

After adding the trace (see modified proc above), the following error occurs:

JVMJZBL2999T ->invokeMain() 
JVMJZBL2999T имя javaClassName: 'de.ubs.du.jdbcserver.Server' 
JVMJZBL2999T Arg 1 = '- p' 
JVMJZBL2999T Arg 2 = '5431' 
JVMJZBL2999T Arg 3 = 'LOG-LEVEL = FINE' 
JVMJZBL1023N Вызов de.ubs.du.jdbcserver.Server.main () ... 
JVMJZBL1056I Аргументы главной ... 
JVMJZBL1057I -p 
JVMJZBL1057I 5431 
JVMJZBL1057I LOG-LEVEL = FINE 
JVMJZBL2999T -> JniUtil.convert () 
JVMJZBL2999T <- JniUtil.convert () 
JVMJZBL2008E Не удалось найти или загрузить класс: de.ubs.du.jdbcserver.Server 
JVMJZBL2999T -> JniUtil.writeStackTrace () 
JVMJZBL2007E След стека: 
java.lang.NoClassDefFoundError: de.ubs.du.jdbcserver.Server 
Вызвано: java.lang.ClassNotFoundException: de.ubs.du.jdbcserver.Server 
.at java.net.URLClassLoader.findClass (URLClassLoader.java:588) 
.at java.lang.ClassLoader.loadClassHelper (ClassLoader.java:756) 
.at java.lang.ClassLoader.loadClass (ClassLoader.java:724) 
.at sun.misc.Launcher $ AppClassLoader.loadClass (Launcher.java:313) 
.at java.lang.ClassLoader.loadClass (ClassLoader.java:703) 
JVMJZBL2999T <- JniUtil.writeStackTrace () 

JVMJZBL2999T <- invokeMain () 
JVMJZBL2999T <- запустить () 
JVMJZBL2999T -> очистка () 
JVMJZBL1014I Ожидание завершения не-демоновых потоков Java перед завершением ... 
JVMJZBL2999T JvmExitHook, введенный с кодом выхода = 0, javaMainReturnedOrThrewException = 0 
JVMJZBL1042E Сбой пакетного запуска JZOS, код возврата = 100 
JVMJZBL2999T Истекшее время DestroyJavaVM = 0,031311 секунды, время ЦП = 0,021000 секунды 
JVMJZBL2999I Истекшее время пакетного запуска JZOS = 7 секунд, время ЦП = 5,090000 секунд 
JVMJZBL1047W Пакетный запуск JZOS завершен с исключением Java, код возврата = 100 
JVMJZBL2999T <- очистка ()

Непонятно, почему мы получаем эту ошибку времени выполнения. На данном этапе это больше не похоже на проблему с разрешениями.

5
задан 12 December 2016 в 18:08
1 ответ

Наконец-то у меня появилось время вернуться к этой проблеме. Первоначальная проблема была довольно неясной. После просмотра нескольких форумов наконец стало ясно, что в члене ACHIM.JDBCSRV.CNTL (SRVENV) произошла ошибка. Он содержал строку:

. /etc/profile

Удаление этого исправило первую ошибку, которая была вызвана неявным «выходом» в конце любого сценария bash. Если вы делаете что-то подобное и действительно нуждаетесь в настройках в скрипте / etc / profile , то я могу только предложить вам скопировать содержимое скрипта в ваши // STDENV данные .

После этого появилась новая ошибка:

java.lang.NoClassDefFoundError: de.ubs.du.jdbcserver.Server

Это было показано в редактировании (3) выше. Оказалось, что это проблема с разрешениями. В задании по настройке разрешений RACF в SYSTSIN DD есть следующее:

OMVS(HOME(/u/zfs4svr)...

Это указывает точку монтирования для файловой системы ZFS, содержащей jar-файлы, используемые JDBCUSR, при запуске задачи. Соответствующее задание монтирования было выполнено пользователем с правами администратора. Соответствующие шаги задания:

//REPRO    EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
  DELETE '<HLQ>.JDBCSRV.ZFS'
  SET MAXCC = 0
  DEFINE CLUSTER ( -
     NAME('<HLQ>.JDBCSRV.ZFS') -
     LINEAR CYL(50 1) -
     SHAREOPTIONS(3,3) -
  )
  REPRO INDATASET(<HLQ>.JDBCSRV.REPRO) -
         OUTDATASET(<HLQ>.JDBCSRV.ZFS)
//****************************************************
//SHELLCMD EXEC PGM=BPXBATCH,COND=(4,LT),
//    PARM='SH mkdir -p /u/zfs4fb'
//SYSPRINT DD SYSOUT=*
//SYSOUT   DD SYSOUT=*
//STDOUT   DD SYSOUT=*
//STDERR   DD SYSOUT=*
//*************************************************
//SHELLCMD EXEC PGM=BPXBATCH,COND=(4,LT),
//    PARM='SH chown -R JDBCUSR:STCGROUP /u/zfs4fb'
//SYSPRINT DD SYSOUT=*
//SYSOUT   DD SYSOUT=*
//STDOUT   DD SYSOUT=*
//STDERR   DD SYSOUT=*
//**************************************************
//SHELLCMD EXEC PGM=BPXBATCH,COND=(4,LT),
//    PARM='SH chmod -R 770 /u/zfs4fb'
//SYSPRINT DD SYSOUT=*
//SYSOUT   DD SYSOUT=*
//STDOUT   DD SYSOUT=*
//STDERR   DD SYSOUT=*
//**************************************************
//MOUNT    EXEC PGM=IKJEFT01,COND=(4,LT)
//SYSTSPRT DD SYSOUT=*
//SYSTSIN  DD *
  MOUNT -
     FILESYSTEM('''<HLQ>.JDBCSRV.ZFS''') -
     TYPE(HFS) -
     MODE(RDWR) -
     MOUNTPOINT('/u/zfs4fb')        

Сложность заключалась в том, что владелец и права для / u / zfs4fb настроены на разрешение доступа JDBCUSR, однако пакеты внутри все еще принадлежат пользователю, который выполняет работу. Мы изменили доступ для чтения / записи к содержимому прямо в OMVS. Это устранило проблему. Чтобы исправить это в сценарии, необходимо изменить порядок шагов задания. В этом случае размещение 2 шагов // SHELCMD с командами chmod и chown после шага // MOUNT устраняет проблему.

Были и другие проблемы с нашей задачей. При инициализации сервера используется свойство user.dir . Я не уверен, где именно, но, похоже, это связано с JVM для z / OS. Потребовалось немного повозиться, так как мы не могли определить, откуда берется значение. При запуске как задание, отправленное администратором (IBMUSER), значение было «/ u / ibmuser». Однако при запуске в качестве запущенной задачи значение было «.», Что вызывало ошибку:

java.lang.ExceptionInInitializerError                         
.at java.lang.J9VMInternals.initialize(J9VMInternals.java:258)
...
Caused by: java.lang.RuntimeException: default directory must be absolute 
.at sun.nio.fs.UnixFileSystem.<init>(UnixFileSystem.java:55)              
...

Исправление заключалось в размещении команды cd / u / zfs4fb в конце // Сценарий среды STDENV . Фактически это может быть любой каталог, для которого пользователь STC (в данном случае JDBCUSR) имеет разрешение на чтение.

Надеюсь, этот обзор поможет кому-то другому, пытающемуся решить подобные проблемы.

0
ответ дан 3 December 2019 в 02:09

Теги

Похожие вопросы