Created attachment 15409 [details]
пример, файла, который авторизует все подряд

Created attachment 15411 [details]
файл для usb

Также, при отключении контроля USB-портов, кнопка "Выключить контроль USB-портов"
Подразумевается что альтератор не вмешивается в работу, но
остаются инструкции для UDEV, которые авторизуют все USB в файле 
/etc/udev/rules.d/99-alterator-ports-access-01-usb-auth.rules

(Ответ для Pavel на комментарий #3)
> Также, при отключении контроля USB-портов, кнопка "Выключить контроль
> USB-портов"
> Подразумевается что альтератор не вмешивается в работу

Вот тут не уверен. Я полагал, что эта кнопка означает, что доступ устройствам не контролируется, то есть — _разрешено всё_! Кажется, так было в одной из первых версий этого модуля и я просто продолжил традицию.

Замечание ваше, впрочем, в целом верное. Но рассматривать вопрос, мне кажется, нужно шире: каким образом модуль должен взаимодействовать с другими правилами udev? Можно как пример рассмотреть ситуацию обратную той, о которой вы сказали: модуль alterator-ports-access что-то _разрешил_ и пользователь ожидает, что устройство подключится, но другие правила udev, выполняющиеся после 99-alterator-ports-access* устройство запрещают. Для пользователя будет совсем не очевидно, почему разрешённое устройство в такой ситуации не подключается.

(Ответ для manowar@altlinux.org на комментарий #4)
> Я полагал, что эта кнопка означает, что доступ
> устройствам не контролируется, то есть — _разрешено всё_!
Тогда надо или не контролировать или переименовать в "разрешено всё". Что-то одно.

(Ответ для Sergey V Turchin на комментарий #0)
> После удаления пакета остаются файлы с правилами udev, мешающие работе
> системы.
Собственно, баг об этом.

https://git.altlinux.org/tasks/344186/

Хех. Не собралось, однако. "check-udev ERROR: udev rules path violation". У нас же теперь запрещено упаковывать файлы из /etc/udev/rules.d.

Что ж теперь? В %post удалять?

В udev-rule-generator так и сделано. Но это костыль, конечно…