ный ход выполнения и передает управление обработчику этого со-
бытия.
- команды манипулирования с полями об®ектов (установить/прочи-
тать обычное/статическое поле).
- команды вызова методов. Их четыре. Команда invokevirtual вы-
зывает (виртуальный) метод на основе анализа информации времени
выполнения. Команда invokenonvirtual осуществляет вызов на ос-
нове информации времени компиляции - например, вызов метода ро-
дительского класса. Команда invokestatic вызывает статический
метод класса. Наконец, команда invokeinterface вызывает метод,
представленный интерфейсом. Выполнение всех перечисленных ко-
манд связано не только с передачей управления, но и с анализом
разного рода таблиц.
- команда возбуждения исключительной ситуации - athrow.
- прочие об®ектные операции (создать об®ект, проверить тип об-
®екта).
- команды сихронизации (войти в критический интервал, выйти из
него).
Мы видим, что не существует семантического разрыва между языком
Java и Java-машиной. Как уже отмечалось, это важно для компакт-
ности скомпилированных Java-программ и для обеспечения высокой
скорости трансляции.
4.2.3. Java и безопасность
Концепция загрузки об®ектов по сети прозрачным для пользователя
образом столь же привлекательна, сколь и опасна. Если не предп-
ринимать никаких мер и не накладывать никаких ограничений на
возможности Java-аплетов, вход на любую Web-страницу может при-
вести к непредсказуемым последствиям. К счастью, разработчики
языка Java с самого начала уделяли самое пристальное внимание
вопросам информациионной безопасности.
Из языка удалены многие потенциально опасные возможности, такие
как оператор goto или тип данных "указатель". Интерпретируемый
характер выполнения позволяет не допустить выхода за границы
массива, обращения по пустой ссылке и т.п. В свое время за по-
добную осторожность выступал автор языка Паскаль Никлаус Вирт,
отмечавший, что при традиционном подходе программист напоминает
моряка, который носит спасательный круг только на суше.
Мы, однако, не будем подробно останавливаться на "обычной" бе-
зопасности и уделим основное внимание выполнению потенциально
враждебных аплетов. Смежный вопрос - проверка подлинности апле-
тов, снабженных электронной подписью, видимо, будет решен в
последующих версиях Java-систем.
Прежде всего, аплетам, загруженным по сети, запрещены чтения и
запись файлов из локальной файловой системы, а также выполнение
сетевых соединений со всеми хостами, кроме того, с которого был
получен аплет. Кроме того, таким аплетам не разрешается запус-
кать программы на клиентской системе (говоря языком ОС UNIX,
для них недоступны системные вызовы fork и exec), им запрещено
загружать новые библиотеки и вызывать программы, внешние по от-
ношению к Java-машине.
На самом деле, перечисленные ограничения не являются частью
спецификации Java-системы и могут выполняться с большей или
меньшей аккуратностью. Так, в Netscape Navigator 2.0 чтение и
запись локальных файлов действительно полностью запрещены. В то
же время, среда разработки JDK 1.0 компании Sun Microsystems
допускает задание списка каталогов, с которыми аплеты могут ра-
ботать.
Более точно, вне разрешенного списка каталогов аплет не может:
- проверять существование файлов;
- читать/писать/переименовывать файлы;
- создавать каталоги;
- проверять атрибуты файла - тип, время последней модификации,
размер.
Чтобы в JDK сделать каталог доступным для аплета, следует по-
местить в файл ~/.hotjava/properties строки вида
acl.read=/home/welcome
acl.write=/tmp
Перед началом работы аплетов они проверяются верификатором бай-
т-кодов. Верификатор убеждается, что загруженный аплет соот-
ветствует спецификациям, заданным при компиляции вызывающей
программы, что не нарушен формат скомпилированного файла, что
нет переполнения или исчерпания стека, нет некорректных преоб-
разований типов, неправильных действий с регистрами и т.п. Все
эти проверки верификатор осуществляет на основе анализа потоков
данных. Особенно тщательно проверяются конструкции finally об-
работчиков исключительных ситуаций.
Следует отметить, что верный выбор баланса между возможностями
загружаемых аплетов и безопасностью клиентской системы является
очень тонким вопросом. Ряд компаний, например, Argus System
Group, предлагают реализовать на клиентской системе усиленные
Читать дальше