Обнаружил следующую проблему - при перезагрузке z/os демон cron в unix-подсистеме запускается, но не выполняет заданий от обычных пользователей. Вот что пишет в лог (/usr/spool/cron/log): > CMD: /u/orabay/ora/orastat.sh > ORABAY 83886336 c Sun Jan 27 22:00:00 2013 setuid failed: uid=4: EDC5139I Operation not permitted. < ORABAY 83886336 c Sun Jan 27 22:00:00 2013 rc=127
orabay - это имя пользователя.
Захожу в telnet под юзером ibmuser, делаю kill процессу cron, снова запускаю: /usr/sbin/cron & и после этого все работает, как надо: > CMD: /u/orabay/ora/orastat.sh > ORABAY 83886384 c Sun Feb 3 22:00:01 2013 < ORABAY 83886384 c Mon Feb 4 06:36:09 2013 rc=0
Вот конец скрипта /etc/rc, в который добавлен запуск cron: # Start the INET daemon for remote login activity BPX_JOBNAME='INETD' /usr/sbin/inetd /etc/inetd.conf & _BPX_JOBNAME=CROND /usr/sbin/cron & sleep 5 echo /etc/rc script executed, `date`
посмотреть под кем реально запускается cron при старте системы. Возможно это не ibmuser.
А также посмотреть у какого юзера UID=4. У ibmuser есть OMVS сегмент? Какие пермишины стоят на скрипте и запускаемых файлах? Есть ли где setUID bit?
По описанию процесс зачем-то попытался изменить права запускаемого процесса. (например если UID поменять с 4 на 0, то все заработает. Можно проверить, но оставлять так конечно не надо. Лучше понять что происходит.)
Т.е. их нужно убрать?Я не помню, зачем они были установлены...
т.е. это работает именно так, как и должно работать setUID бит вызывает изменение эффективного UID на UID владельца файла (т.е. ORABAY) при запуске этого файла. А UID, с которым запускается сам CRON, у Вас, похоже, не 0, и потому процесс не может сменить UID. Если нужно, чтобы скрипт выполнялся именно с UID ORABAY, то простейшим способом это можно сделать так: разрешить процессу cron SetUID root (RACF BPX.SUPERUSER в классе FACILITY), владельцем скрипта сделать root а в начале скрипта выполнять su orabay, или выполнять его su orabay orastat.sh, а s-бит, естественно, убрать. Однако, должен отметить, что все это создает дырень в безопасности... Так что Вы сначала все же определитесь, с какими правами должен выполняться orastat.sh. Возможно, лучше будет выполнять этот скрипт в пакетном задании (EXEC PGM=BPXBATCH) с нужным USER= в JOB, а само это задание запускать из CRON...
Сообщение отредактировал Gregory - Ср, 08.05.2013, 01:00
Спасибо, мы подумаем. А где можно посмотреть, как загружается Unix подсистема? В частности, от имени кого запускается содержимое /etc/rc?
Добавлено (08.05.2013, 09:02) --------------------------------------------- Судя по ps -Af, системные процессы запускаются от юзера DFS. Я так понимаю, это аналог root на этой платформе? Если зайти как ibmuser и сделать "su -", получится именно DFS.
Имя не всегда правда. Используется UID из OMVS сегмента, а имя первого найденного пользователя. Если у вас несколько пользователей имеют UID=0, то рисуется тот что в алфавите первый.
Хочется знать uid DFS? (лучше в RACF посмотреть) Заодно UID ibmuser на всякий случай.
Наверно еще хочется знать как вы cron запускаете? Где вы его прописали? Перед убийством cron посмотрите под кем он запущен.
Есть десяток способов дать права, мне кажется стоит посмотреть в RACF кто прописан в FACILITY BPX.DAEMON
The additional control that BPX.DAEMON provides involves the use of kernel services such as setuid() that change a caller's z/OS user identity. Any user can issue a setuid() which follows a successful __passwd() call to the same target user ID. However, a user with daemon authority can issue setuid() without knowing the target user's password.
Есть десяток способов дать права, мне кажется стоит посмотреть в RACF кто прописан в FACILITY BPX.DAEMON
я думаю, что это хороший (если не лучший) способ. ПисАл пост #6 поздно вечером и как-то забыл про BPX.DAEMON.
Цитата (XOpen)
Имя не всегда правда.
Конечно. Имя в USS, как и в UNIX, не имеет значения, значение имеет только UID. Superuser это не root, а UID 0 :-) В USS связь USERID - UID в RACF, в UNIXах - в /etc/passwd (/etc/security/passwd).
z/OS UNIX System Services Planning 15.6.4.3 Steps for customizing the cron daemon
When you are done, the cron daemon has been customized and can be started.
It must be started by a userid with READ permission to the BPX.DAEMON resource profile in the FACILITY class. (For more information about BPX.DAEMON, see "Setting up the BPX.* FACILITY class profiles" in topic 4.9 and "Establishing the correct level of security for daemons" in topic 15.3.)
Без SetUID orabay получит другие права и либо сам не сможет в свои же файлы зайти, либо сможет зайти в туда куда ему не положено. Думаю вызовут кого-то в воскресенье ночью все разгребать...
Ничего страшного. Это не настолько важное задание ;-)
Добавлено (15.05.2013, 13:18) --------------------------------------------- Кстати, забыл написать - задание нормально сработало и без SetUID и SetGID. Теперь надо подождать перезагрузки z/os, чтобы убедиться в том, что и после нее все будет хорошо. Правда, когда будем перезагружать, неизвестно. Может, через год
Добавлено (13.08.2013, 08:31) --------------------------------------------- Здравствуйте. Вот произошла перезагрузка мэйнфрейма. Но записи в логе те же самые
Код
*** cron started *** pid = 33554436 Mon Aug 5 03:20:45 2013 > CMD: /u/orabay/ora/orastat.sh > ORABAY 67109714 c Sun Aug 11 22:00:01 2013 setuid failed: uid=4: EDC5139I Operation not permitted. < ORABAY 67109714 c Sun Aug 11 22:00:01 2013 rc=127
