zVlad wrote: WLM - недавнее изобретение ИБМ. Эта штука, в отличии от традиционного планирования по приоритетов, может обеспечивать достижения неких целей (goal mode), требуемых разными процессами (например процент CPU, или время ответа, или ... я не знаю что). WLM сам разберется кому и когда и какой приоритет назначить. Т.е. в конечном счете он конечно через приоритеты управляет, но он их постоянно потстраивает, чтобы ь заданым цели были достигнуты.
Ну, не такой уж он и новый. Я припоминаю, что году в 1998-99 примерно мне пришлось уже активизировать WLM, потому что какой-то очередной компонент IBM без него не работал (чуть ли не Unix System Services???). Но в WLM помимо Goal Mode была также Compatibility (? кажется) Mode, - и тогда он работал по до-WLM-ским алгоритмам. Вот и активизировали WLM Compatibility Mode (во избежание недоразумений в банковской production system). Этого было достаточно для тех компонентов, кому этот WLM был обязательным.
И к тому же в то время WLM входил в поставку OS/390, дополнительные деньги не требовались. Теперь это изменилось что ли? (Хотя, деньги были не мои; может, и в то время банк за все уплатил? )
Я теперь работаю с "удаленным доступом", компьютер стоит в другом штате, и про новые Systems Programmer's штучки знаю плохо.
Я к сожалению не имею возможность исследовать WLM в глубь. Но точно знаю, этот парень не приблуда, а концептуальная вещь. Например, некоторые возможности дисковой подсистемы ИБМ ESS "Shark" могут быть использованны только если есть WLM.
И это нужно не для запуска утилит вообще, а для запуска утилит как хранимых процедур. До WLM, хранимые процедуры выполнялись в специальном адресном пространсте, все в одном.
А вообще в системе может быть до 5+х aдресных пространств (каждое из этих пространств образует кучу threads):
DSNMSTR - главный координатор, SQL машина и Stage2 поиска данных
DSNDBM1 - ввод-вывод, и Stage1 поиска
DSNIRLM - менеджер блокировок . Используется не только DB2 а всеми продуктами требующими блокировки.
DSNDDF - удаленный доступ к DB2 через протокол DRDA.
DSNSPAS - выполнение хранимых процедур и пользовательских функций
DSNWLMх (х - количество хранимых процедур выполняемых в среде WLM) - выполнение хранимых процедур в наиболее защищенном режиме. А поскольку утилиты - критичные программы, выполнение их как хранимых процедур возможно только здесь.
К вопросу как выглядит DB2 с точки зрения системы. Не как обычное приложение. И не только DB2. В МVS имеется понятие подсистема, и кстати CPU mainframe имеет не только привилигированные и проблемные команды, но также "semi-privilеge" команды, видимо для поддержки подсистем типа DB2. Не знаю, могут ли быть NT Services аналогами подсистем в MVS? Кстати SQL в NT - это Service?
Кроме того имеется DB2 код, который активизируется системой в процессе начальной загрузки независимо от того будем мы запускать DB2 или нет. Этого кода может и быть если мы вообще не планируем мспользовать DB2 на данной системе.
"........3.2+3.3 Почему ? Как это связано ?"
Моя программа и вызванная ею утилита будут выполняться в одном адресном пространстве с одним и тем же ключом защиты памяти, и следовательно моей программе будут доступны области памяти утилиты и она сможет вмешиваться в процесс общения утилиты с DB2. А это требует санкции.
".........Допустим у меня есть супер пупер полномочия на команду SQL "ALTER INDEX name СДЕЛАТЬ_ФИГНЮ" .....
То есть если я пользователь A, то я могу сделать это набрав этот оператор в некоей графической утилите, в COnsole...."
В отношении ALTER-а, который есть оператор SQL, это так но в случае утилиты - нет.
"......3.2 я совсем не понял. Почему надо следать ЗА ПРОГРАММАМИ ?"
Точнее было бы сказать - система НЕ позволяет неавторизованным программам запускать авторизованные. Мне кажется это логично.
".......Похоже в IBM с DB2 ответственность за проверку полномочий на некоторые довольно стандартные операции базы (которые Вы изволили назвать "опасными" - что есть негативный опыт ? ) ложится на операционную систему. Совершенно непонятно почему."
И так и не совсем так. Часть функций по контролю осуществляет ПОДсистема RACF (Resource Access Control Facility), который используется всеми в MVS (аналогичный продукт имеется в VM и AIX). Например, ваш запрос даже не дойдете до компоненты работающей с удаленными конекциями DSNDDF, если у вас нет READ прав на так называемый "facility class profile" с именем DSN.DIST, который определен в RACF. Проверка полномочий, например, на получение данных из таблицы Таб1 может осуществляться самой DB2, но также может быть делигирована RACF. В нашей установке это делает DB2, но я планирую передать это RACF - просто хочу попробовать, но скорей всего это ужесточит защиту и без того достаточно сильную. Может быть разгрузит DB2. Пока не знаю.
Вообще, ИБМ строит свои продукты модульно. Если есть модуль управления блокировками, то он используется всеми, модуль защиты (хотя как мы видели DB2 имеет и свой внутренний механизм) - тоже, модуль управления транзакциями CICS - всеми кому нужен механизм транзакций (DB2 как положено базам данных имеет свой механизм в том числе two-phase commit, конечно, но через CICS вы можете объединять в транзакции не только работу реляционных, и не только баз данных.В VM напрмер есть файловая система с возможностью отката, видимо и в MVS есть).
Location: SPB --> Gloucester, MA, US --> SPB --> Paris
Postby Dmitry67 »
zVlad wrote:1 Моя программа и вызванная ею утилита будут выполняться в одном адресном пространстве с одним и тем же ключом защиты памяти, и следовательно моей программе будут доступны области памяти утилиты и она сможет вмешиваться в процесс общения утилиты с DB2. А это требует санкции.
2 Точнее было бы сказать - система НЕ позволяет неавторизованным программам запускать авторизованные. Мне кажется это логично.
1 Не понял, не можете ли пояснить
Грубо говоря утилита (рассуждаю с точки зрения знакомства с Win/Linux/VAX/VMS/RSX) это исполняемый файл (EXE). Когда он выполняется, то по определению работает в своем собственном адресном пространстве
То что работает в том же адресном пространстве (DLL) как правило используется для того чтобы быстро выполнять какую то функцию.
Все, кажется понял. Утилита в понимании IBM Более похожа на DLL, который делает чтото хитрое и опасное. Отсюда проблемы.
Непонятно почему нельзя запускать утилиту в отдельном адресном пространстве и общаться с ней по сети. Все проблемы сразу снимаются
2 Не совсем
Вот например у вас есть exec permission на процедуру X. Процедура X делает select из таблицы Y. Допустим у Вас нет привилегии на четие из таблицы Y. Вопрос: что будет при запуске процедуры X в DB2 ?
В MS SQL она благополучно отработает, и это правильно (готов подробно пояснить почему)
Ухожу буду в понедельник
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
SVK wrote:
"Ну, не такой уж он и новый. Я припоминаю, что году в 1998-99 примерно мне пришлось уже активизировать WLM, потому что какой-то очередной компонент IBM без него не работал (чуть ли не Unix System Services???). Но в WLM помимо Goal Mode была также Compatibility (? кажется) Mode, - и тогда он работал по до-WLM-ским алгоритмам. Вот и активизировали WLM Compatibility Mode (во избежание недоразумений в банковской production system). Этого было достаточно для тех компонентов, кому этот WLM был обязательным....."
Да, ты конечно прав, это мы недавно скакнули на 2.10 с 1.6. USS у нас работает. Наоборот я знаю, что без USS MVS нынче не работает. ОК, залогинился, смотрю, торчит в активных задачах WLM. Может он в Compatibility (да есть такой), а той хр. процедуре нужен именно Goal Mode? Я нынче не системный, я DBA. Поэтому меня все равно не пустят чтото в системе менять.
"....И к тому же в то время WLM входил в поставку OS/390, дополнительные деньги не требовались. Теперь это изменилось что ли? (Хотя, деньги были не мои; может, и в то время банк за все уплатил? )...."
Он и сейчас входит и "забесплатно". Ясный пень chargе-ат за все. WebSphere тоже входит за так.
"Я теперь работаю с "удаленным доступом", компьютер стоит в другом штате, и про новые Systems Programmer's штучки знаю плохо." Взаимно...
"1 Не понял, не можете ли пояснить
Грубо говоря утилита (рассуждаю с точки зрения знакомства с Win/Linux/VAX/VMS/RSX) это исполняемый файл (EXE). Когда он ............
Непонятно почему нельзя запускать утилиту в отдельном адресном пространстве и общаться с ней по сети. Все проблемы сразу снимаются"
Вообще то утилиты работают автономно. Я ее запускаю с определенным заданием(мя), она их выполняет (или нет если что-то не так), строит репорт и завершается. С ней нет возможности (так впрочем и надобности) общаться.
".........2 Не совсем
Вот например у вас есть exec permission на процедуру X. Процедура X делает select из таблицы Y. Допустим у Вас нет привилегии на четие из таблицы Y. Вопрос: что будет при запуске процедуры X в DB2 ?
В MS SQL она благополучно отработает, и это правильно (готов подробно пояснить почему)......."
В свете твоего примера DB2 постапает также точно. Но SQL - это ведь не программы, запускаемые в системе. Система (MVS или NT) про SQL и таблицы ничего не знает, но вот программы, выполняемые в системе должны подчиняться некоторым требованиям безопасности. В MVS на этот счет имеется понятие авторизации программ.
Наскока я понял на мэйнфрейме есть одна операционка - MVS. Все остальное уже не имеет прямого доступа к железу, только через MVS. А MVS отточена годами - это раз. Не делает ничего кроме проверки прав того или иного приложения (включая все VM) - это два. Если довести MVS до уровня винды по финкциональности или дать поставить на мэйнфрейм ось без посредничестве MVS (то есть прямой доступ до железа из, скажем линукса), то дырявость общей системы будет сопоставима с дырявостью той-же оси на любом другом железе. Аппаратная защита в мэйнфрейме примерно такая-же как в писюке. А далее все софт.
r00t wrote:Наскока я понял на мэйнфрейме есть одна операционка - MVS. Все остальное уже не имеет прямого доступа к железу, только через MVS. А MVS отточена годами - это раз. Не делает ничего кроме проверки прав того или иного приложения (включая все VM) - это два.
Если отвечать в двух словах - то всё совсем не так. И операционок есть несколько разных. И делает MVS намного больше, чем сам Windows. И делала большую часть из того, что делает сейчас, ещё когда Windows даже "в проекте" не было...
А вообще - понятно, что этот топик не имеет смысла продолжать. Как уже было отмечено выше.
r00t wrote:
"Наскока я понял на мэйнфрейме есть одна операционка - MVS......"
Нет. Имеется как минимум три оси:
MVS - multiple virtual storage
VM - virtual machine, много лет назад имели место быть дискуссии, а можно ли ось считать осью поскольку собственно операционной среды эта система не дает, хотя сочетание VM/CMS - это конечно операционная среда. Основная особенность VM в том что на виртуальных машинах можно грузить любые системы МФ, в том числе саму VM, а в той другую и так далее пока не надоест. Гениальная система. Не имеет аналогов. В настоящее время овновное рекламируемое направление эффективного использования - выполнение множества Linux-ов (сотни). MVS может быть загружен на виртуальную машину под VM.
VSE - самая древняя из ныне здравствующих систем. Появилась в 1964 под названием DOS/360. В следующем будет празновать 40 летие. Притерпела множество изменений, используется и поддерживается ИБМ-ом до сих пор.
Linux - может грузиться на виртуальные машины VM, но может также быть единственной системой управляющей целым мэйнфрэймом. Такой вариант я лично не воспринимаю. Хотя ИБМ предлагает.
"......Все остальное уже не имеет прямого доступа к железу, только через MVS....." - не верно смотри выше.
"....... А MVS отточена годами - это раз......" - точно
" Не делает ничего кроме проверки прав того или иного приложения (включая все VM) - это два....." права проверяет подсистема RACF, имеющаяся также в VM-е и AIX.
" Если довести MVS до уровня винды по финкциональности......." - если сравнивать сервер-винду с MVS то на самом деле MVS представляет много большую функциональность чем винды. Достаточно сказать что MVS и VM каждый обладает фукциональностью Unix, дополнительно к своей очень не бедной функциональности. Клиентские GUI программы - это сфера персоналок, хотя терминальный режим MVS имеет всё необходимое для написания диалоговых программ.
"...... или дать поставить на мэйнфрейм ось без посредничестве MVS (то есть прямой доступ до железа из, скажем линукса), то дырявость общей системы будет сопоставима с дырявостью той-же оси на любом другом железе. Аппаратная защита в мэйнфрейме примерно такая-же как в писюке. А далее все софт."
Про Linux ничего не могу сказать. Про аппаратную защиту.... мое мнение, что МФ имеет принципиально иной уровень аппаратной защиты, я приводил выше пример на Ассемблере и никто мне не показал ничего подобного для ПК. Tengiz дал ссылку на документ по i386, вот прочитаю его может быть смогу найти правильный ответ. Если Вы хотите показать что i386 и МФ имеют одинаковый уровень аппаратной защиты - приведите аналогичные моим примеры на Ассемблере. Да и тогда все равно останется разница в том как работает ввод-вывод.
zVlad wrote:Про аппаратную защиту.... мое мнение, что МФ имеет принципиально иной уровень аппаратной защиты, я приводил выше пример на Ассемблере и никто мне не показал ничего подобного для ПК. Tengiz дал ссылку на документ по i386, вот прочитаю его может быть смогу найти правильный ответ. Если Вы хотите показать что i386 и МФ имеют одинаковый уровень аппаратной защиты - приведите аналогичные моим примеры на Ассемблере. Да и тогда все равно останется разница в том как работает ввод-вывод.
zVlad, никто Вам ничего не показал просто потому, что вся эта беседа - натуральный Кафка по степени сюрреализма. ЛЮБАЯ интересующая Вас информация доступна в интернете. Причём того времени, которое Вы потратили на набор текстов, содержащих вопросы по поводу реализации защиты в современных микропроцессорах уже вполне хватило бы для того, чтобы получить все необходимые ответы.
Вот Вам код для Visual C++ с заплатками на ассемблере, который при запуске под Windows на Интеле вызовет исключения при попытке выполнить привелигированные инструкции в пользовательском режиме, включая ввод/вывод и попытки изменить MSW и управляющие регистры подсистемы виртуальной памяти. Ровно то же самое получится на Linux - код, разумеется, придётся переделать, чтобы его можно было номально скомпилировать gcc:
int main (int argc, char** argv) { // let's try to issue a basic IO instruction // __try { _asm mov dx, 0x300 _asm in al, dx // <- this will cause EXCEPTION_PRIV_INSTRUCTION } __except (ExFilter (GetExceptionCode ())) { }
// what if we try to load the local descriptor table register? // __try { _asm mov eax, 0x12345678 _asm lldt [eax] // <- this will cause EXCEPTION_PRIV_INSTRUCTION } __except (ExFilter (GetExceptionCode ())) { }
// Ok, lets load the CR0 control registers (machine status word) // __try { _asm mov CR0, eax // <- this will cause EXCEPTION_PRIV_INSTRUCTION } __except (ExFilter (GetExceptionCode ())) { }
// Hm... how about loading page directory register? // __try { _asm mov CR3, eax // <- this will cause EXCEPTION_PRIV_INSTRUCTION } __except (ExFilter (GetExceptionCode ())) { } }
Location: SPB --> Gloucester, MA, US --> SPB --> Paris
Postby Dmitry67 »
zVlad wrote: Моя программа и вызванная ею утилита будут выполняться в одном адресном пространстве с одним и тем же ключом защиты памяти, и следовательно моей программе будут доступны области памяти утилиты и она сможет вмешиваться в процесс общения утилиты с DB2. А это требует санкции.
zVlad wrote:Вообще то утилиты работают автономно. Я ее запускаю с определенным заданием(мя), она их выполняет (или нет если что-то не так), строит репорт и завершается. С ней нет возможности (так впрочем и надобности) общаться.
Вот и возникает вопрос: если это выглядит как вызов процесса с другими параметрами (аналог вызова команды "чтото .EXE параметры") то нахрена это делать в том же адресном пространстве ???
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
Для того чтобы точно знать когда и как вызваная утилита завершилась. Общаться в процессе выполнения не надо, но знать когда и как завершилась таки надо. В настоящее время, запуская утилиту как автономную единицу, я (программа) должен в цикле опрашивать систему типа "а как там задание такое-то, не завершилось ли?". И как только система ответит "да мол завершилось", идти и смотреть а как она завершилась. Not big deal, of course.
zVlad wrote:Для того чтобы точно знать когда и как вызваная утилита завершилась. Общаться в процессе выполнения не надо, но знать когда и как завершилась таки надо. В настоящее время, запуская утилиту как автономную единицу, я (программа) должен в цикле опрашивать систему типа "а как там задание такое-то, не завершилось ли?". И как только система ответит "да мол завершилось", идти и смотреть а как она завершилась. Not big deal, of course.
То есть прерывания и сигналы в мире мэйнфреймов еще не изобрели ?: Так и тратят циклы CPU на опросы ?
ЗиВлад, скажите, зачем вы начитаете разговор о вирусах, в которых ни ухом ни рылом ? Да еще столь сильными утреждениями типа "мэйнфремы unbrakeble, потому что у них есть аппаратные средства защиты" ? Вы в курсе, что досовских вирусов, дописывающих себя в конец exe файла, или там бутовых каких, уже не производят ? Все норовят макрос присобачить, или по сети залезть. Вирусописатели вышли на новый уровень абстракции, на котором аппаратные средства - как мертвому припарки. Так что вас от вирусов спасает, как тут правильно заметили, положение "неуловимого Джо" плюс большой штат высокооплачиваемых админов, а вовсе не некие аппаратные преимущества.
А пристыдишь их - и сальцо найдется, и горилочка...
zVlad wrote:Для того чтобы точно знать когда и как вызваная утилита завершилась. Общаться в процессе выполнения не надо, но знать когда и как завершилась таки надо. В настоящее время, запуская утилиту как автономную единицу, я (программа) должен в цикле опрашивать систему типа "а как там задание такое-то, не завершилось ли?". И как только система ответит "да мол завершилось", идти и смотреть а как она завершилась. Not big deal, of course.
zVlad, что-то здесь не так. Даже в самых примитивных операционных системах типа UNIX или NT не нужно так делать: циклический опрос системы о состоянии определённого задания с целью последующего вычитывания кода завершения - это пустое сжигание циклов процессора, не говоря уже о том, что это вообще может не работать без того, чтобы система была в курсе, что кого-то интересует код завершания определённого процесса. Иначе идентификаторы процессов/заданий, или что там однозначно их адресует, нельзя было бы повторно использовать до следующего перезапуска системы.
)
