Por que o hostnamectl não requer uma senha para alterar o nome do host?

Question

Parece que a nova maneira de mudar o nome do host com o systemd é:

hostnamectl set-hostname NEWNAME

No entanto, isso não requer uma senha quando conectado como usuário com direitos de administrador (não tenho certeza de qual grupo conta). No caso de usuários não administradores, ele abre uma caixa de diálogo solicitando a senha de um dos usuários privilegiados.

Acho que "shutdown -h now" funciona até para usuários não administradores.

Eu suponho que estes são ambos os novos comandos relacionados ao systemd.

Como eles verificam se o usuário que envia os comandos tem o direito de executá-los? Como posso fazê-los pedir uma senha ou exigir sudo?

    

Answer 1

Em systemd e utilitários relacionados, as ações que podem exigir acesso privilegiado são roteadas por meio do PolicyKit. Execute pkaction sem nenhum parâmetro para ver a lista de todas as possíveis ações manipuladas pelo PolicyKit. Para ver a política atual de uma ação específica, use pkaction --verbose --action-id <action identifier . Por exemplo, alterando o nome do host:

# pkaction | grep host
org.freedesktop.hostname1.set-hostname
org.freedesktop.hostname1.set-machine-info
org.freedesktop.hostname1.set-static-hostname

# pkaction --verbose --action-id org.freedesktop.hostname1.set-hostname
org.freedesktop.hostname1.set-hostname:
  description:       Set host name
  message:           Authentication is required to set the local host name.
  vendor:            The systemd Project
  vendor_url:        http://www.freedesktop.org/wiki/Software/systemd
  icon:              
  implicit any:      auth_admin_keep
  implicit inactive: auth_admin_keep
  implicit active:   auth_admin_keep

Portanto, a política atual do meu sistema para alterações de nome de host é auth_admin_keep - ou seja, exigir uma senha de um administrador a menos que o usuário tenha passado com êxito por uma verificação semelhante (como sudo pode evitar pedidos de senha consecutivos).

E quem é um administrador cuja senha pode autorizar essas ações? No meu sistema Debian 9, isso é determinado pelos arquivos no diretório /etc/polkit-1/localauthority.conf.d/ - por padrão, apenas o root e os membros do grupo de usuários sudo se qualificarão.

Se você não gosta dessa política, pode facilmente alterá-la escrevendo alguns arquivos de configuração personalizados do PolicyKit.

O PolicyKit pode ser configurado para exigir os seguintes "níveis de segurança" para qualquer ação gerenciada por ele:

• yes - o usuário sempre pode fazer isso, sem perguntas
• auth_self_keep - se o usuário não fez nada recentemente solicitando uma verificação de senha, solicite a senha do usuário para garantir que ele realmente seja ele / ela. Se várias ações consecutivas desse nível forem executadas dentro de uma janela de poucos minutos, as verificações poderão ser ignoradas após a primeira.
• auth_self - sempre exige verificação de senha do usuário
• auth_admin_keep - requer a senha de um usuário administrativo. Assim como auth_self_keep , depois que a senha (e opcionalmente o nome de usuário do administrador) for inserida uma vez, o usuário poderá executar várias ações desse nível em uma breve janela de tempo sem solicitações adicionais de senha
• auth_admin - sempre exige uma verificação de senha e o usuário que está respondendo à verificação de senha deve ser um dos usuários administrativos
• no - a ação é rejeitada sem mais perguntas.

A hora em que os resultados ..._keep são mantidos é aparentemente codificada no código upstream do PolicyKit: aqui está um link para o PolicyKit Git.

/* TODO: right now the time the temporary authorization is kept is hard-coded - we
 *       could make it a propery on the PolkitBackendInteractiveAuthority class (so
 *       the local authority could read it from a config file) or a vfunc
 *       (so the local authority could read it from an annotation on the action).
 */
 expiration_seconds = 5 * 60;

Atualmente, não parece haver nenhuma provisão para configurar este valor em tempo de execução, nem para estender o registro de tempo de autenticação depois de definido.

O OpenSuSE parece ter estendido isso com ...keep_session e ...keep_always resultados. Aparentemente, eles também reinterpretaram as ações ...keep para "lembrar o resultado enquanto o processo de solicitação continuar rodando".