Дело о пропавшем автозапуске
Я рассказываю об изменениях в ядре ОС Windows Vista с момента проведения конференции TechEd US летом 2006 года, и одной из функций, которой я в своем докладе уделяю внимание, является ReadyBoost. Это технология кэширования на диске со сквозной записью, которая позволяет повысить производительность системы за счет размещения кэша диска на флэш-накопителе. Принцип работы ReadyBoost достаточно подробно описан в моей статье «Внутренности ядра ОС Windows Vista, часть 2», опубликованной в журнале TechNet Magazine. Вкратце, он заключается в следующем: поскольку флэш-носители характеризуются значительно меньшей задержкой при произвольном доступе, чем жесткие диски, технология ReadyBoost перехватывает операции доступа к диску и перенаправляет операции чтения методом произвольного доступа в кэш, если, конечно затребованные данные в нем имеются. При этом операции последовательного доступа производятся на диске. В ходе презентации я подключил к компьютеру флэш-накопитель USB, ожидая увидеть диалоговое окно автозапуска с предложением организовать на накопителе кэш ReadyBoost.
Первая презентация прошла удачно, а вот во время двух последующих диалоговое окно автозапуска не появлялось. Готовясь к презентациям перед докладами, я уже замечал подобные случаи, но в силу нехватки времени не имел возможности провести полноценное расследование. Чтобы обойти проблему, я вручную открывал диалоговое окно свойств тома после подключения устройства. В результате страницу ReadyBoost можно было вызвать щелчком на ссылке "Speed up my system" (Ускорить работу системы) в диалоговом окне автозапуска.
Перед последним докладом, который я должен был сделать на ноябрьской конференции TechEd/ITforum в Барселоне, у меня нашлось время, чтобы разузнать, с какой, собственно, стати не работает автозапуск. В первую очередь, я проверил его настройки, которые находятся в секции AutoPlay (Автозапуск) страницы Hardware and Sound (Оборудование и звук) панели управления. Некоторым параметрам было присвоено значение Ask me every time (Спрашивать каждый раз), но, по-видимому, они игнорировались, и даже после возврата к настройкам по умолчанию автозапуск работать не возжелал.
Далее требовалось разобраться в том, как на подключение устройства реагируют реестр и файловая система. Решение этой задачи могло помочь найти причину, по которой проводник не обращал внимания на настройки автозапуска в панели управления. Я запустил программу Process Monitor, настроил фильтр, отбирающий операции проводника с реестром, а затем повторно подключил флэш-носитель. Остановив запись событий, я приступил к изучению собранного материала.
Для исследования 22 000 событий потребовались бы многие часы, а поскольку конкретные коды ошибок, на которые следовало бы обратить внимание, не были мне известны, пришлось искать ключевое слово, которое смогло бы придать верное направление моим поискам. Первая попытка - поиск по слову “autoplay” - не принесла никакого результата. Известно, что проводник ищет в корневом каталоге съемного носителя файл Autorun.inf, в котором содержатся указания о значке тома и исполняемом файле, который должен запускаться по двойному щелчку пользователя на томе. Поэтому для второй попытки я избрал ключевое слово "autorun". В первой найденной строке не оказалось ничего интересного - она ссылалась на идентификатор GUID точки подключения. Эти сведения ОС Windows генерирует динамически при обнаружении нового устройства.
Следующие строки, не сильно отдаленные от первой, ссылались на значения реестра, содержащие параметры групповых политик.
Запросы по первым двум путям завершались ошибкой NAME NOT FOUND (ИМЯ НЕ НАЙДЕНО), из чего можно было сделать вывод о том, что политики не определены, а вот запрос по пути HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoDriveTypeAutoRun оказался успешным. Программа Process Monitor показала значение, считанное проводником, в столбце Details (Сведения).
Поскольку я не знал, как трактовать значение 255, пришлось провести поиск в Интернете по строке "nodrivetypeautorun". В результате я нашел страницу из комплекта ресурсов для Windows 2000. В ней объяснялось, что указанное значение представляет собой маску, которая определяет, с каких типов устройств автозапуск должен быть запрещен. Как выяснилось, десятичное значение 255 (шестнадцатеричное 0xFF) отключает автозапуск со всех устройств.
Далее посредством функции перехода (Jump-To) программы Process Monitor я запустил редактор Regedit и перешел непосредственно к указанному значению. Открыв редактор значений, я заменил старое значение нулем, что должно было разрешить автозапуск с любых устройств. Теперь нужно было проверить, что изменилось. Я отключил, а затем вновь подключил к компьютеру флэш-накопитель. На экране появилось диалоговое окно автозапуска, что и требовалось доказать. Стоит иметь в виду, что в ОС Windows Vista автозапуск больше не работает по принципу «автоматически запустить то, что указано в файле Autorun.inf». Новый принцип - «показать возможные варианты» - не создает угроз безопасности.
Дело было почти раскрыто - за исключением одного обстоятельства, с которым стоило разобраться. Блокировка автозапуска в моей системе произошла согласно конфигурации групповых политик в домене Майкрософт, к которому она подключена. Это объясняет, почему во время первых моих докладов автозапуск работал - в то время я еще не перешел на работу в корпорацию. Из этого также можно было заключить, что в следующий раз при подключении к домену конфигурация групповых политик вместе с упомянутым значением будет восстановлена. Случись мне подключиться к домену до доклада, автозапуск снова пропадет.
Увы, существует лишь два способа избежать восстановления параметров групповых политик: либо не подключаться к домену, либо вовсе выйти из него. Правда, в силу наличия прав администратора я могу скорректировать разрешения, регламентирующие доступ к разделу реестра, таким образом, что групповые политики не смогут его менять. Поскольку обработка параметров групповых политик производится в контексте системной учетной записи, я открыл редактор разрешений Regedit и запретил ей доступ на запись.
Теперь можно было не сомневаться, что я не попаду впросак во время текущей серии докладов об изменениях в ядре ОС Windows Vista, а равно и в ходе любых докладов в будущем. Дело было раскрыто. Рассмотренный пример подчеркивает не только ценность программы Process Monitor при поиске причин неполадок, но и широкие возможности локального администратора. Локальный администратор - это полноправный хозяин компьютера. Он вправе делать с ним все, что угодно, в том числе обходить политики домена (об этом я рассказывал в одной из предыдущих записей). По этой причине, хотя и не только по ней, предприятиям стоит ограничивать своих сотрудников правами стандартных пользователей.