Como posso ativar a sessão atual no ConsoleKit?

Question

Eu tenho um sistema Debian Squeeze ao vivo em uma unidade USB, contendo um script que eu uso para a imagem de outra unidade. Esse script usa udisks para montar uma unidade por rótulo, mas não funciona em um console serial. O motivo é que a sessão associada ao console serial não parece estar "ativa", o que significa que udisks falha com:

user@my-live-usb:~$ udisks --mount /dev/disk/by-label/image-data --mount-options ro
Mount failed: Not Authorized

Alterar a chave allow_any em /usr/share/polkit-1/actions/org.freedesktop.udisks.policy não ajuda, por isso gostaria de saber como dizer ao ConsoleKit que o console serial está "ativo". Tentando fazer isso através da interface DBUS falhar:

user@my-live-usb:~$ dbus-send --system --print-reply --dest="org.freedesktop.ConsoleKit" /org/freedesktop/ConsoleKit/Session7 org.freedesktop.ConsoleKit.Session.Activate
Error org.freedesktop.DBus.GLib.UnmappedError.CkSeatError.Code0: Unable to activate session

A sessão 7 é aquela listada como estando em / dev / ttyS0.

Então, como faço para o ConsoleKit reconhecer o console serial como uma sessão ativa?

(No meu caso, a versão do udisks é 1.0.1 + git20100614-3, o consolekit é o 0.4.1-4.)

Também vale a pena notar que o sistema live Debian registra automaticamente o usuário ao vivo em todos os 6 consoles de vídeo e no console serial.

    

Answer 1

O objetivo é configurar uma sessão ativa do ConsoleKit. Você pode verificar isso via:

$ ck-list-sessions | grep active
    active = TRUE

Se houver várias sessões do ConsoleKit, apenas uma sessão, no máximo, poderá estar ativa por vez.

Se a saída for algo como

$ ck-list-sessions | grep active
    active = FALSE
    active = FALSE

você tem um problema porque coisas que precisam de uma sessão ativa do ConsoleKit para autenticar o envio de mensagens pelo dbus não funcionam (por exemplo, NetworkManager, por exemplo, nm-applet , udisk ...).

Existem vários métodos para criar (e ativar) uma sessão do ConsoleKit. O gerenciador de exibição pode configurar um via comunicação direta com o daemon ConsoleKit. Ou um módulo pam pode fazer isso. Ou um login / script X11-session-init pode chamar ck-launch-session, que deve criar uma sessão ativa (modulo bugs).

Normalmente, o objetivo deve ser configurar o ConsoleKit de tal forma que você obtenha uma sessão ativa para o gerenciador de janelas ou shell de login (não apenas para scripts únicos).

Para testar o sistema ConsoleKit, você pode tentar usar ck-launch-session para criar uma sessão apropriada do consolekit. Por exemplo, você pode chamar seu script assim:

$ ck-launch-session ./script

Para testar se o ck-launch-session está livre de bugs, você pode chamar

$ ck-launch-session ck-list-sessions

e verifique se existe uma sessão ativa.

Bugs: Atualizações no sistema ConsoleKit introduzidas recentemente várias bugs no frágil (e super engenharia) do ecossistema ConsoleKit.

Por exemplo, no meu sistema Ubuntu 11.10 eu tive que apagar nox11 da linha pam_ck_connector.so em /etc/pam.d/common-session depois que ck-launch-session parou de funcionar depois de uma atualização do sistema:

--- a/pam.d/common-session      Fri May 25 10:26:53 2012 +0200
+++ b/pam.d/common-session      Fri May 25 10:39:41 2012 +0200
@@ -29,5 +29,5 @@
 session        required        pam_unix.so 
 session        optional                        pam_winbind.so 
 session        optional        pam_ecryptfs.so unwrap
-session        optional                        pam_ck_connector.so nox11
+session        optional                        pam_ck_connector.so
 # end of pam-auth-update config

Com essa mudança agora, recebo diretamente uma sessão active ao iniciar meu gerenciador de janelas via WDM login.

Isso significa que o gerenciador de janelas agora é executado dentro de uma sessão ativa do ConsoleKit e tudo que é iniciado como filho do processo de gerenciador de janelas (por exemplo, de um xterm) também faz parte dessa sessão, ou seja, sem necessidade de chamadas extras de ck-launch-session para eg nm-applet mais.

    

Answer 2

Eu tive um problema com a sessão, em que is-local e active era FALSE . /bin/login usou pam_ck_connector para fazer uma sessão apropriada. Então eu executei o xinit com ck-launch-session openbox em ~/.xinitrc . A segunda sessão foi quebrada.

A solução NÃO é usar ck-launch-session , mas execute xinit permanecendo no mesmo terminal virtual e mantendo ativa a primeira sessão local existente: XINITRC=/path_to_custom/xinitrc xinit -- :1 vt1