Usando o startx no Fedora 17, um usuário não-root não pode se juntar a novas redes sem fio - como consertar?

Question

Eu tenho o Fedora 17 instalado em um Lenovo X230, e se eu deixá-lo configurado para inicializar no Gnome usando o runlevel5.target (ou graphical.target) do systemd, que é o padrão, a rede parece funcionar bem - um local O usuário pode ingressar em uma nova rede sem fio, autenticando e salvando uma senha de rede conforme necessário. Até agora tudo bem.

No entanto, o proprietário deste laptop prefere inicializar em uma exibição não gráfica (runlevel3.target ou multi-user.target do systemd); quando desejado, ele executa startx para iniciar o Gnome. Quando o Gnome é iniciado dessa maneira, o usuário não pode ingressar em nenhuma nova rede sem fio; você pode selecionar o SSID desejado na lista suspensa, mas nenhum prompt para senha de rede será exibido e nenhuma conexão será feita. Não vejo nada relevante registrado em / var / log / messages.

O que pode ser feito para que um usuário não privilegiado que tenha iniciado o Gnome usando startx possa participar de novas redes sem fio?

Notas:

Se o root efetuar login, iniciar o Gnome e ingressar na nova rede sem fio, os novos arquivos apropriados serão criados em / etc / sysconfig / network-scripts para as informações de rede e chave. Feito isso, o usuário não-root pode usar a rede sem fio quando fizer o login. Essa solução alternativa é terrivelmente inconveniente.

O usuário já é membro do grupo 'wheel' e tem acesso completo ao sudo sem senha. O SELinux está desativado nesta máquina.

Como teste, adicionei o usuário ao grupo 'root' e fiz o / etc / sysconfig / network-scripts group-writable. Isso não ajudou nem mudou nada.

    

Answer 1

Resposta curta - use:

 startx -- vt0

Explicação mais longa: Os links e sugestões do @JimParis levaram-me a mergulhar um pouco mais no PolicyKit e systemd, e - crucialmente - pesquisar no Google por "polkit startx", o que me levou a um resultado em um site de discussão do Arch Linux :

If you don't use a display manager, it means you won't have a registered pam session for your graphical login, which means logind won't give the correct info to polkit (it will think that there is no active session).

A workaround for this is to start your WM on the same VT as your consolelogin, and hence "steal" that pam session. I believe the magic incantation is:

# startx -- vt0

Até agora, eu nem percebi que o startx pode levar argumentos mas isso funciona lindamente para a minha situação. Não só o usuário local pode agora junte-se a redes sem fio corretamente, mas tem acesso adequado a outras áreas de trabalho do Gnome recursos como bluetooth e suspensão.

    

Answer 2

Meu palpite é que, quando você executa startx , não tem uma sessão ativa de ConsoleKit . Veja por exemplo Configure as permissões do PolicyKit na entrada wiki do Arch Linux para o NetworkManager. Ele mostra como usar ck-launch-session no seu ~/.xinitrc para garantir que você tenha uma sessão de CK adequada.

Você também precisa garantir que as permissões PolicyKit estão corretas, embora elas provavelmente já estejam bem se as coisas funcionarem dentro de um Sessão do Gnome.

Se o comando ck-list-sessions mostrar uma diferença entre usar runlevel5.target versus runlevel3.target + startx , esse provavelmente é o seu problema.

Veja também:

Administração e privilégio na parte inferior da página de configuração do Network Manager.

Eu não recomendo que você siga o que eles dizem sem entender o que eles estão fazendo, já que não é necessariamente claro como eles se relacionam com o Fedora, mas eles podem ser úteis para ler:

Esse bug do Ubuntu: Se 'startx' for executado dentro de um console de texto, a sessão do ConsoleKit será não marcado como 'ativo'

Esta publicação da lista de discussão do Debian que contém alguns detalhes sobre a alteração das permissões do policykit / consolekit: Re: What é o caminho certo para usar o consolekit com startx?