Да, я сам проверил, указанные мной ключи блокруют совсем другое - это запрет на монтирование сетевых ресурсов. В теме по указанной Вами ссылке описывется уже отчасти обсуждавшийся на этом форуме способ блокировки cdrom. Давайте я их перечислю, чтобы было от чего плясать.
1) Простейшие способы - сказать, что нельзя показывать определенный диск в эксплорере (или запретить на него заходить). За это отвечают два ключа в реестре, они элементарно обходятся пользователем при использовании файлового менеджера, отличного от эксплорера.
2) Удаление устройства из профиля оборудования - данный способ плох тем, что после изменения профиля оборудования нужна перезагрузка. Кроме того, пользователь может просто перегрузить машину в отсутствии системного администратора, и выбрать желаемый профиль. Если же просто отключить устройство в данном профиле, то администратор в случае нужды должен будет сначала включить устройство, перегрузиться, поработать, отключить - перегрузиться.
3) Остановка служб, отвечающих за работу floppy и cdrom. Недостаток тот же - необходима перезагрузка, единственное улучшение состоит в том, что пользователь не сможет самостоятельно запустить службу.
4) Вышеупомянутые ключи - относятся только с сети, в принципе очень важны - но только если мы сначала сможем отключать локальный cdrom.
5) Физическое отключение "нужных" проводков.
Теперь относительно некотоых изысканий, которые я провел.
На сайте
www.sysinternals.com есть
интересная статья о драйверах в NT. Там сказано, что все драйвера устройств по умолчанию при создании имеют доступ "Все:R/W", и сетуется на то, что это плохо, надо мол только "R". В нашем случае с cdrom надо бы вообще запретить доступ.
С помощью Regmon я постарался отследить, в какой момент происходит монтирование устройств как DosDevices. Оказалось, что очень рано, причем (емнип) от имени SYSTEM. В обшем-то все правильно, поскольку остальным программам/драйверам могут понадобиться уже смонтированные диски. Дальше все стало немного непонятнее. В своей статье Mark Russinovich пишет, что для имеющихся в системе устройств можно с помощью его утилиты WinObj посмотреть ACL. Я посмотрел, даже поизменял. Но вот загвоздка - изменения ACL для CDfs и Device CDROM0 ничего не меняют, кроме доступа к самим объектам (реестра, надо полагать). Сам драйвер исправно обслуживает пользователей и далее, не глядя на ACL. Вторая непонятка состоит в том, что для примонтированной cdfs (т.е. при вставленном диске) менять разрешения вообще нельзя. Третья проблема в том, что после перезагрузки устройства опять создаются с "Все:R/W".
Интересно, что сам Mark Russinovich приводит пример "правильного драйвера" (с исходниками), который шарит в ACL. Но тут же уточняется, что там "функции недокументированные". Остается только недоумевать, почему все так сложно у майкрософтовцев. Может они расчитывали, что драйвера cdrom.sys будут писать третьи фирмы-произволители этих самых cdrom, да и пожадничали при передаче документации? Или дело в другом?
Вообще, включение/отключение cdrom "на ходу" может быть очень болезненным. Если программа, читающая данные с диска, вдруг окажется отрезанной по уровню привилегий, она может "упасть". Если же ошибка произойдет в cdrom.sys, упадет драйвер, а за ним и систему сможет "скривить". Предвижу замечание: так ведь в настоящее время можно вытащить диск - ну и поругается система, ну и что? Не знаю... Короче, понятно, что ничего не понятно.
Ладно, у кого какие предложения еще будут, пишите здесь, обсудим.
А я в третий раз убедился, что
нельзя ограничить доступ к локальному cdrom средствами реестра.
PS. Есть еще 6-й способ, имхо. В управлении компом можно скрыть букву диска для cdrom. Но я еще не проверял, нужна ли будет перезагрузка и вообще есть ли в этом смысл.
