Защита ресурсов (уровень 30)

We use cookies. Read the Privacy and Cookie Policy

Защита ресурсов (уровень 30)

Минимальным рекомендуемым уровнем защиты является уровень 30. На этом уровне, так же как и на уровне 20, для входа в систему пользователь должен быть зарегистрирован и знать правильный пароль. После входа в систему проверяется, обладает ли пользователь правами доступа к системным ресурсам; несанкционированный доступ не разрешается. На уровне 30 пользователь также может быть зарегистрирован с ограниченными возможностями.

Отдельным пользователям могут быть предоставлены права доступа к системным объектам, таким как файлы, программы и устройства. Обеспечивают такую возможность профили пользователя, и вскоре мы поговорим подробнее о том, каким образом они это делают. Мы также рассмотрим другие варианты наделения пользователя правами доступа к системным объектам: с помощью групповых или общих прав.

Уровень защиты 30 был наивысшим в System/38. Но на нем не различаются пользовательские объекты и объекты, используемые только ОС. В связи с доступностью на System/38 ассемблера MI и наличия определенной информации о внутренней структуре объектов возникла серьезная проблема. ISV стали писать прикладные пакеты, зависящие от внутренней структуры объектов, что нарушало технологическую независимость MI.

В первых моделях AS/400 использовались те же самые уровни защиты. Хотя в AS/ 400 не было ассемблера MI, и мы не публиковали информацию о внутренних структурах, специалисты довольно скоро поняли, что AS/400 — это System/38. Поэтому программы, зависимые от внутренней структуры объектов, работали и на AS/400.

Мы понимали, что при переходе к клиент/серверным вычислениям, AS/400 нужна более надежная защита, блокирующая доступ к большинству внутренних объектов. В связи с переходом на RISC-процессоры изменениям подверглась и внутренняя структура. Но если бы мы просто реализовали новый, повышенный, уровень зашиты, то программы, зависимые от внутренней структуры объектов, перестали бы работать, что вызвало бы недовольство заказчиков.

Мы объявили о том, что собираемся встроить в V1R3 новый уровень защиты, и что на этом уровне доступа к внутренним объектам не будет. Мы также начали искать тех ISV, кто использовал внутренние объекты, чтобы предоставить им стандартные системные API, с информацией, необходимой для их программ.

Большая часть таких программ были утилитами, использовавшими информацию некоторых полей внутри системного объекта. Например, системе управления магнитной лентой могли понадобиться некоторые данные о заголовке ленты. Такую информацию можно было получить единственным способом — проникнув в системный объект. Мы создали сотни API для предоставления подобной информации через MI (по сути дела, эти API были новыми командами MI) и гарантировали, что они будут работать во всех последующих версиях ОС. Таким образом мы развязали себе руки и начали вносить изменения во внутренние структуры.

С защитой связана еще одна серьезная тема: тема открытости AS/400. Довольно долго многие ISV не только использовали внутренние объекты, но и настаивали, чтобы IBM сделала внутреннее устройство ОС открытым и дала тем самым «зеленый свет» разработчикам ПО. В ответ IBM утверждала, что при неправильном использовании команд MI велика вероятность программных сбоев, за которые она не может нести ответственность. Компромисс (управляемая открытость через API) был достигнут, частично в результате серии заседаний группы COMMON, начатых по инициативе ISV и других пользователей. Работу с ISV и определение новых API возглавил Рон Фесс (Ron Fess) — один из основных разработчиков ПО с большим опытом работ по CPF и OS/400. Результат это работы — реализация на AS/400 Single UNIX Specification и других стандартных API. AS/400 стала более открытой для пользователей.