On Fri, Mar 04, 2011 at 09:30:22AM +0600, Alexey Petrakov wrote: > В сообщении от 3 марта 2011 18:34:54 автор Sergey Vlasov написал: > > On Thu, Mar 03, 2011 at 11:57:57AM +0600, Alexey Petrakov wrote: > > Для монтирования права доступа к блочному устройству не требуются. > > Жаль. Такой удобный механизм, очень печально что его похерили. На самом деле его там никогда и не было - в любом случае фактическое монтирование выполняется от root, а обычный пользователь может что-то смонтировать либо через suid-программу, либо через обращение к другому процессу, имеющему права root (hald, udisks-daemon). Ограничения типа опций owner и group в fstab на самом деле реализованы в /bin/mount; у hald есть свои правила, udisks-daemon не имеет собственных файлов конфигурации и управляется через установку переменных окружения в правилах udev. [...] > > (Documentation/usb/authorization.txt): [...] > Спасибо. Ознакомился. На мой взгляд, это в некоторой мере стрельба > из пушки по воробьям. И, к тому же, там, как я понял, реализован > принцип "сначала запретим всё что каается УСБ, а потом будем > разрешать что можно", а мне нужно наоборот "можно всё, кроме > указанного", да и разгребать баги с отвалившимися мышами, > клавиатурами и принтерами не хочется совсем. По-другому сделать просто нельзя - после обнаружения устройства, если authorized_default не установлено в 0, к нему сразу привязывается драйвер, если соответствующий модуль загружен. Единственный надёжно работающий способ - ничего не делать с устройством, пока не будет получено разрешение от userspace. Логику "можно всё, кроме указанного" можно попробовать реализовать на уровне правил udev - вместо записи сразу в ATTR{authorized} можно сначала устанавливать значение какой-нибудь переменной окружения (первым правилом установить в 1 для всех USB-устройств, последующими правилами сбросить в 0 для ненужных), а в последнем правиле записать окончательное значение переменной в ATTR{authorized}. Хотя тут возникает проблема из-за того, что атрибут authorized находится на уровне устройства, а привязка драйверов происходит к интерфейсам, находящимся уже на следующем уровне иерархии объектов sysfs (кстати, из-за этого ещё возникнет вопрос, что делать с многофункциональными устройствами, имеющими одновременно с интерфейсом Mass Storage и другие интерфейсы - через атрибут authorized можно запрещать доступ только к устройству целиком). > На данный момент наиболее адекватным считаю следующее правило удева: > > SUBSYSTEM=="block", DRIVERS=="usb-storage", NAME="" Менять NAME в документации уже давно не рекомендуются, и вроде бы тоже грозились совсем запретить (раньше это было нужно для некоторых устройств, для которых ядро не выдавало полные имена самостоятельно, но сейчас это уже починено в самом ядре). Уже сейчас при обнаружении установки NAME udevd сыпет ошибками. > Если я в чём-то не прав - с радостью приму замечания. Есть ещё один вариант - выставить /sys/bus/usb/drivers_autoprobe в 0, а потом в случае обнаружения разрешённого устройства записывать его bus_id либо в /sys/bus/usb/drivers_probe (разрешая ядру самостоятельно выбрать подходящий драйвер), либо в bind для конкретного драйвера. http://www.kernel.org/pub/linux/kernel/people/gregkh/driver_core/2.6/2.6.21/driver-core-udev-triggered-device-driver-binding.patch Правда, в этом варианте тоже изначально отключается всё - без правил udev, разрешающих привязку драйверов к нужным устройствам, ничего работать не будет. Однако, в отличие от варианта с authorized, есть возможность разрешать использование только части интерфейсов устройства. Кроме того, этот способ работает не только с USB. Есть и совсем грубый способ - запретить загрузку модуля usb-storage через /etc/modprobe.d/*.conf: install usb-storage /bin/true При этом могут появиться сообщения об ошибках в случае подключения устройств, обслуживаемых не самим модулем usb-storage, а другими модулями, зависящими от него (поддержка некоторых "странных" устройств сейчас вынесена в отдельные модули ums-*); из-за наличия таких модулей недостаточно написать "blacklist usb-storage" (blacklist действует только на запросы указанного модуля, но не блокирует загрузку его по зависимостям из других модулей). При наличии USB 3.0 надо блокировать и модуль uas.