pare o systemctl usando o prompt gráfico do sudo

pare o systemctl usando o prompt gráfico do sudo

Minha pergunta é como posso configurar o systemd (?) Para parar de abrir esse pop-up irritante sempre que me esqueço de digitar sudo. Basta me fornecer um prompt sudo baseado em texto ou mostrar um erro, para que eu possa corrigir o erro rapidamente.

Este é o Arch Linux, mais recente (systemd 238.133).

insira a descrição da imagem aqui

Responder1

Este não é um prompt 'sudo', é um prompt 'polkit'. Uma maneira de evitá-lo – global paratodossoftware, não apenas systemctl – é escrever uma regra polkit que negue imediatamente a ação (ou a permita imediatamente).

polkit.addRule(function(action, subject) {
    if (subject.user !== "root") {
        if (/^org\.freedesktop\.systemd1\./.test(action.id)) {
            return polkit.Result.NO;
        }
    }
});

(O subject.userteste pode ser omitido, pois as ações invocadas pelo root ignoram totalmente as verificações do polkit.)

As regras do polkit são armazenadas em /etc/polkit/rules.d/*.rules, geralmente denominadas como 80-custom.rules(processadas em ordem crescente). Para mais informações, vejapolkit(8).


(Dito isto, se a sua configuração do sudo não tiver senha, não há diferença prática de segurança entre usar 'sudo' e fazer com que o polkit permita imediatamente a ação. E vice-versa, se o seu sudorequeruma senha... então por que não inseri-la na caixa de diálogo do polkit? É a mesma senha.)

Responder2

Existe uma opção --no-ask-password. Crie um apelido:

alias systemctl='systemctl --no-ask-password'

(testado em Bash, Kubuntu).

Responder3

Não use sudo para systemctl,sempre; se vocêsãoautorizado a fazer a manutenção, configure o polkit corretamente.

Justificativa: sudofaz com que o programa que você executa efetivamente pelo usuário solicitado (normalmente: root). Incluindo todos os kits de ferramentas vinculados. Qualquer bug no programa, bibliotecas ou ... configuração do sudo torna você vulnerável. No caso de systemd, o systemctlbinário é apenas umcontrolador(em geral). Istonãorequer privilégios de root (para a maioria dos casos de uso), pois não executa operações privilegiadas por si só, mas solicita init. Usar a conta real root(diretamente ou via sudo) é uma solução atômica (bomba) do tipo tudo ou nada, enquanto oapenascoisa que é necessária éautorizar(não: autenticar)contrasystemd. Já que systemdentende polkitporautorização, usandoautenticadorootsão muitas permissões concedidas.

Considere um bug no systemctl, que permite invocar comandos arbitrários diretamente (não via systemd). Quando rootas permissões são concedidas por sudo, pode-se executar qualquer comando com EUID=0. Ao systemctlexecutar como usuário sem privilégios, só é possível executar esse comando com a conta que ele obteve acesso anteriormente. Esta é uma consequência simples de algumas regras básicas de segurança:

  • use apenas o conjunto de permissões necessárias (não o conjunto completo == root),
  • conceda essas permissões apenas ao código que as exige (autorize systemdsem conceder permissões a systemctl).

Quanto a ser o único usuário de uma máquina - se você trabalha com uma conta não privilegiada, e não aquela root, presumo que você queira impedir que programas executados obtenham permissões supérfluas. Concedê-los systemctlapenas porque a rootconta é authorizedcomandar systemdé uma permissão supérflua.

Além disso, polkitvocê pode ter diferentes critérios de acesso para diferentes ações (iniciar/parar/recarregar/qualquer coisa) e diferentes serviços. Você pode colocar comandos exatos sudoers, mas a solução polkit está ciente das partes específicas de tais comandos.

Concluindo: não use sudose algum método menos privilegiado estiver disponível. sudoé uma solução de último recurso do tipo tudo ou nada.

Se você quiser que o prompt de senha seja mostrado em texto, não gráfico, bastadesativar DISPLAY, por exemplo:desvincule seu terminal da sessão gráfica, que executa o agente de autenticação.

informação relacionada