LWN.net - GNOME, Wayland e variáveis de ambiente
Strode, apesar de querer avançar para uma solução “moderna” para variáveis ambientais, está claramente sentindo a pressão que vem de uma exposição mais ampla de um sistema quebrado. Assim, seu comentário mais recente sobre o bug, no momento em que este livro foi escrito, dizia: "Sim, estou pensando em desistir disso." Portanto, é provável que o Fedora 25 veja uma atualização que restaure o shell de login para o processo de login; uma "correção adequada" aguardará mais tarde.
Agora é o Fedora 28... onde estamos no lado da "correção adequada" das coisas? Já existe uma maneira futura para os usuários definirem variáveis de ambiente para suas sessões?
Ou seja, um substituto ~/.bash_profileque funciona no Fedora e, esperançosamente, em outros lugares.
Responder1
Para GNOME 3.24, Strodesessão gnome revertidapara carregar variáveis de ambiente executando um shell de login.
No mesmo comentário, eles incluíram um patch para gnome-session para enviar essas variáveis de ambiente de sessão para serviços de usuário do systemd. Estes incluem gnome-terminal, por isso é bastante importante :).
O iniciador da sessão GDM já estavacorrigidoem 3.22, para importar o ambiente do systemd --user. Portanto, o ambiente systemd é importado para a sessão, modificado pelo shell de login e o resultado também é copiado de volta para systemd --user.
O que deve funcionar bem... exceto testes no Fedora 28, não funciona corretamente para, por exemplo, PATH, porque o inicializador de sessão do gdm não permite que variáveis de ambiente do systemd substituam o ambiente pré-existente.Eu relatei isso no rastreador de problemas do GNOME.
Eraacordadoisso login(para o console de texto)poderiaaceite algum patch para carregar a configuração do ambiente antes de iniciar o shell do usuário, mas não há nenhuma mudança até agorautilitário-linux v2.32.
Eu nem me preocupei em procurar patches ssh :).
O ambiente systemd já era configurável no user.conf. Como parte desse esforço, o systemd v233ganhouum environment.d/formato que agora suporta, por exemplo, anexar um diretório extra às listas existentes PATHou LD_LIBRARY_PATHde pesquisa.
Achei que o melhor lugar para definir variáveis de ambiente para logins de usuários seria em um módulo PAM - até pam_envjá o fizemos. A lógica sendo
pedir login, gdm, sshd (isso nunca acontecerá), etc. para fazer isso é realmente uma solução ruim.
Infelizmente, a configuração do pam_envé irritantemente inconsistente entre as distros... e parece que pode ter havido uma boa razão para isso. A ~/.pam_environmentcaracterísticaé considerada uma grande "arma" para segurança. Veja tambémCVE-2010-4708.
Veja
pam_execpor exemplo. Você poderia imaginar um administrador de sistema usando-o para fazer alguma configuração de pós-login ou algo assim, mas um usuário poderia obter root configurando LD_PRELOAD. Ou pam_selinux na verdade usa pam_getenv diretamente, então um usuário pode mexer com ele. Mas meu ponto não são realmente esses exemplos específicos, é apenas para ilustrar que há riscos em fazer isso como root, e podemos contornar esses riscos completamente, eliminando toda uma classe de possíveis bugs de segurança, fazendo isso um pouco mais tarde no processo de login. Como regra geral, se você não precisa de código para rodar como root, ele não deve rodar como root! Claro, ainda estou indeciso, porque logisticamente é mais estranho fazer isso mais tarde, mas não tenho dúvidas de que fazer isso como root é mais arriscado do que como usuário.O manual pam_exec afirma explicitamente: "Os comandos chamados por pam_exec precisam estar cientes de que o usuário pode ter controle [sic] sobre o ambiente."
ré. pam_env, observe que o fedora o coloca no topo da pilha pam e desativa ~/.pam_environment por padrão.
Colocá-lo no topo da pilha é um bug e viola o aviso explícito de não fazer isso: "Como a configuração das variáveis de ambiente PAM pode ter efeitos colaterais em outros módulos, este módulo deve ser o último na pilha."
[...] Dada a confusão aqui, esta é obviamente uma arma de pé
A idéia geral de usar a configuração do shell para isso também parece funcionar, por exemplo, no login gráfico do Ubuntu Desktop 16.04. Há uma diferença, no entanto. O Fedora cria ~/.bash_profilepor padrão, o que (para o bash) faz com que ~/.profileseja ignorado. Ubuntu e outras distribuições baseadas em Debian são criadas ~/.profilepor padrão. (Ou seja, esses arquivos são fornecidos quando você cria um novo usuário, a partir de /etc/skel).
(Eu usei isso no Ubuntu recentemente. O Ubuntu parece ter mudado ao longo do tempo ao executar um shell de login para sessões GUI. Por exemplo, consultehttps://superuser.com/questions/183870/difference-between-bashrc-and-bash-profile/183980#183980,https://askubuntu.com/questions/40287/etc-profile-not-being-sourced,"Por que o gnome-terminal não é um shell de login", e"O que significa login do shell ('bash -l')").