PolicyKit запусти.

Это всё этот ваш долбаных HAL? Не понимаю, как люди дошли до того, что монтирование устройств зависит от графической среды. Этожжесть.

> Это всё этот ваш долбаных HAL?
Как бы это уже не HAL, это именно PolicyKit.

как люди дошли до того, что монтирование устройств зависит от графической среды

Это не зависит от графической среды, просто Gnome сам запускает сессию PolKit, а Openbox - нет.

Ну пакет этот у меня есть, вопрос- что это и как это «запустить». В /usr/bin и /usr/sbin следов этого не обнаружил, в /var/run впрочем есть директория с таким именем, пустая. Что же это и с чем его едят?

Ответ нашелся здесь

После этого вроде монтируется, но, не отмонтирывается, с тем же сообщением) Ну umount /media/sdb1 работает конечно. Наверно, чтобы и отмонтировать можно было из файлового менеджера нужно в тот же policykit.conf добавить ещё и что нибудь вроде:

<match action="org.freedesktop.hal.storage.umount-removable">

^^ В том направлении мыслю?

> что это и как это «запустить»
Это такая штука, которая управляет правами доступа.
Во-первых, какой у тебя менеджер входа? По-идее Gdm и Kdm сами должны запускать демон PoliciKit :) У меня, например, стоит Slim, настроенный так, что при логине пользователя выполняет файлик .Xsession из домашней папки пользователя. А в нем у меня вот такая хитрость: exec ck-launch-session startxfce4.
Для опенбокса соответственно будет: exec ck-launch-session openbox-session.

>> Это всё этот ваш долбаных HAL?

Как бы это уже не HAL, это именно PolicyKit.

Спасибо что уточнил.
А зачем оно, господа, нужно? Автомаунт даёт при втыкании? Я сижу на 32м ядре, весь софт последний, но слышу про это чудо первый раз. Монтирую всё в консоли.

> А зачем оно, господа, нужно?
Ну потому что решили выкинуть hal, а заменить его нечем, вот и строят костыли, один другого краше.

Я сижу на 32м ядре, весь софт последний

$ pacman -Qs kit | egrep -e '/(.*)kit'

Автомаунт даёт при втыкании?

Автомонтированием занимаются пользовательские приложения, а не HAL.

HAL это прослойка между железкой и программой, которая хочет с этой железкой работать. Например, воткнул мышку в порт, udevd ее определил и сделал файл устройства, hal взял и основываясь на своих правилах применил какие-то настройки (например отключил колесико мыши), X.org обратился к hal и получил уже настроенную по правилам мышь.

В чем профит? В том, что для Х.org можно не держать файл xorg.conf, где заранее указано устройство и его настройки, а использовать хотплаг по заданным политикам.

Но великие разработчики решили, что hal не нужен, и понаделали костылей в виде *kit. В итоге у нас есть кучка китов, которые умеют работать только с дисками и флешками, и ни с чем более. А уж devicekit-power просто поражает своей функциональностью.

Т.е. это всё для даунов, которые не осилили xorg.conf получается?

> Т.е. это всё для даунов, которые не осилили xorg.conf получается?
А что, ты без HAL можешь подключить хот-плаг устройство (например клавиатуру) без перезагрузки X.org? Я думаю, что нет. Смысл-то в том, чтобы сделать подключение устройств вообще незаметным для пользователя. Воткнул в юсб мышку - она заработала, воткнул клавиатуру - она заработала, и не надо править конфиг и перезапускать иксы. Естественно, что кому-то это не надо, ну тогда выключите HAL, используйте драйверы mouse и kbd, и монтируйте устройства руками. В чем проблема-то? :]

Идея понятна, наверное, нубам будет полезно. Лично мне не нужно, я аппаратуру меняю гораздо реже, чем, например, обновляю ядро. Так что поправить конфиг и перегрузиться не проблема.

>подключить хот-плаг устройство (например клавиатуру) без перезагрузки X.org?

И, кстати, это, можно сделать, если устройство заранее известно. У меня, например, подключаюся автоматом мыша, клава и дисплей, когда я ноут на док кидаю. Но они все, есс-но, прописаны в конфиге.
Так что ограничение только в добавлении ранее неизвестных устройств.

> Так что ограничение только в добавлении ранее неизвестных устройств.
Ну как бы как.. К халу есть такие довески как policykit :)

Например, нельзя чтобы пользователи группы untrusted использовали флешки, выносные диски и т.д., но в то же время, чтобы пользователи группы trusted могли это делать. Добавляется правило, по которому всем, кроме trusted запрещено монтировать устройства, а дальше уже сам hal разруливает эти правила.

Ну или например, есть группа пользователей russian, нужно чтобы клавиатура для этих пользователей всегда была с русской раскладкой, для english - только с английской.

Примеров можно придумать много, hal полезная штука, но на него все забили, так что ждем появления кучки различных *китов, каждый со своими конфигами.

>Например, нельзя чтобы пользователи группы untrusted использовали флешки, выносные диски и т.д., но в то же время, чтобы пользователи группы trusted могли это делать. Добавляется правило, по которому всем, кроме trusted запрещено монтировать устройства, а дальше уже сам hal разруливает эти правила.

Это настраивается обычными правами

Ну или например, есть группа пользователей russian, нужно чтобы клавиатура для этих пользователей всегда была с русской раскладкой, для english - только с английской.

А это вообще какой-то изврат непонятный. Давайте ещё придумаем права для пользователей, которым можно нажимать только цифры 0-5 и нельзя остальные.

Однако)

Ну во- первых у меня xdm, в его Xsession соответственно написано exec openbox-session, это то понятно) Что же вы конкретно предлагаете мне добавить в Xsession?

Сейчас я все прекрасно монтирую из консоли, но разобраться то нужно.

> соответственно написано exec openbox-session
Поменяй на: exec ck-launch-session openbox-session

Да, проблема решена

Большое спасибо за помощь, буду очень благодарен если вы расскажете что это за ck-launch-session. Будет ли такой способ работать в других дистрибутивах (клнкретно в дебиане и арче)? Может действительно проще монтировать из консоли?

>Это настраивается обычными правами

Пример неудачный. Вот другой пример.

1. Входит user1, монтирует флешку1. 2. Переключаемся, входим как user2, монтируем флешку2.

user1 должен видеть флешку1, и не видеть флешку2 и наобороть.

Вот подобной ерундой и занимается ConsoleKit, правами такое никак.

> буду очень благодарен если вы расскажете что это за ck-launch-session
Запускалка сессии ConsoleKit :)

Будет ли такой способ работать в других дистрибутивах

Да, везде где программы собраны с поддержкой Hal.

Интересная идея. Первый раз о таком слышу. Лично Вам это будет удобно? Монтируем фшелку от пользователя, нужно что-то поправить админом, ему приходится перемонтировать. И дублирование обратных операций...

Мне как кому? Как одному из этих пользователей? Ну я не сильно хотел бы, чтобы моя флешка была видна другому. А админ.. админ разберется, рута никто не отменял.

Ну я не сильно хотел бы, чтобы моя флешка была видна другому.

При этом оставляешь флэшку воткнутой (физически досягаемой) и покидаешь зону видимости. Немного надуманно, нет?

Ничего я не покидаю, попользоваться дал, сижу рядом, пью чай и вообще с моей флешки идет копирование. Не нужно за меня юзкейс додумывать.

Я надеюсь, что тебе известно, что при физическом доступе все меры безопасности теряют смысл, если не поставить TPM какой-нибудь. Так может мне сразу давать рутовый пароль всем, кто садится за мой комп?

А что, ты без HAL можешь подключить хот-плаг устройство (например клавиатуру) без перезагрузки X.org? Я думаю, что нет.

Вы думаете неправильно. если в xorg.conf для мышки указано /dev/mice то любое мышеустройство (в т.ч. некоторые тачпады) будет передавать туда события о перемещениях\кликах, которые и будут обрабатываться иксами. с клавами точно так же (во всяком случае с юсб клавами).

1. /dev/input/mice, а не /dev/mice

2. За то, что такое есть - спасибо ядру, они и убрать вообще-то могут.

3. Для клав /dev/input/keyboards ядро не предоставляет, поэтому не получится с клавой без хала или удева. Можно конечно иксами сканить /dev/input/*, но там может появится не только клава или мышь.

Итого - udev нужен, hal - нет, что собственно сейчас и происходит с иксами.

как я понимаю, с клавами все дело обстоит иначе, чем с мышами. Система подразумевает одну(?) клавиатуру. Вот это предложение я пишу с только что подключеной юсб клавы. конфиг иксов таков:

Section "InputDevice"
    Identifier     "Keyboard1"
    Driver         "kbd"
    Option         "AutoRepeat" "500 30"
    Option         "XkbRules" "xorg"
    Option         "XkbModel" "pc104"
    Option         "XkbLayout" "us,ru"
    Option         "XkbVariant" ",winkeys"
    Option         "XkbOptions" "grp:ctrl_shift_toggle"
EndSection

До подключения юсб клавы была пс\2.

Я про мышку писал? И /dev/input/mice это не hal.

А что, ты без HAL можешь подключить хот-плаг устройство (например клавиатуру) без перезагрузки X.org? Я думаю, что нет. Смысл-то в том, чтобы сделать подключение устройств вообще незаметным для пользователя. Воткнул в юсб мышку - она заработала, воткнул клавиатуру - она заработала, и не надо править конфиг и перезапускать иксы. Естественно, что кому-то это не надо, ну тогда выключите HAL

Вот на что были ответом мои посты в этой теме. без хал иксы кушают хотплаг клавиатуры и юсб мыши. Для меня этого более чем достаточно, поэтому я считаю что хал в иксах вещь бесполезная и даже вредная.