Para o GNOME 3.24, o Strode reverteu a sessão do gnome para carregar variáveis de ambiente executando um login concha.
No mesmo comentário, eles incluíram um patch para o gnome-session para empurrar essas variáveis de ambiente de sessão para os serviços do usuário do systemd. Estes incluem gnome-terminal , por isso é bastante importante:).
O lançador de sessões do GDM já estava corrigido no 3.22, para importar o ambiente de systemd --user . Assim, o ambiente systemd é importado para a sessão e, em seguida, modificado pelo shell de login, e o resultado também é copiado de volta para systemd --user .
O que deve funcionar ok ... exceto o teste no Fedora 28, ele não funciona corretamente, por exemplo, PATH, porque o ativador de sessões do gdm não permite que variáveis de ambiente systemd sobrescrevam o ambiente pré-existente. Eu relatei isso no rastreador de problemas do GNOME .
Foi acordado que login (para o console de texto) poderia aceite algum patch para carregar a configuração do ambiente antes de iniciar o shell de usuários, mas não há nenhuma alteração até agora em util-linux v2.32 .
Eu nem me preocupei em procurar por patches ssh:).
O ambiente systemd já era configurável em user.conf . Como parte desse esforço, o systemd v233 ganhou um formato environment.d/ , que agora suporta, por exemplo, prefixando um diretório extra para as listas de pesquisa PATH ou LD_LIBRARY_PATH existentes.
Eu achei que o melhor lugar para definir variáveis de ambiente para logins de usuários seria em um módulo PAM - nós até temos pam_env . A lógica é
asking login, gdm, sshd (that'll never happen), etc. to do this is really a poor solution.
Infelizmente, a configuração de pam_env é irritantemente inconsistente entre distros ... e parece que pode ter havido uma boa razão para isso. O recurso ~/.pam_environment é considerado um grande "footgun" para segurança . Veja também CVE-2010-4708 .
Look at
pam_execfor instance. You could imagine a sysadmin using it to do some postlogin configuration or something, but a user could get root by setting LD_PRELOAD. Or pam_selinux actually uses pam_getenv directly, so a user could screw with it. But my point isn't really these specific examples, it's just to illustrate there are risks from doing it as root, and we can bypass those risks entirely, eliminating a whole class of potential security bugs, by doing it just a little later in the login process. As a general rule, if you don't need code to run as root, it shouldn't run as root! Of course, I'm still torn, because logistically, it's more awkward to do it later, but there's no question in my mind that doing it as root is riskier than doing it as the user.O manual pam_exec afirma explicitamente: "Comandos chamados por pam_exec precisa estar ciente de que o usuário pode ter controle [sic] sobre o ambiente ".
re. pam_env, note fedora puts it top of the pam stack and disables ~/.pam_environment by default.
Colocá-lo no topo da pilha é um erro e viola o explícito aviso para não fazer isso: "Desde configuração de variáveis de ambiente PAM pode ter efeitos colaterais para outros módulos, este módulo deve ser o último um na pilha. "
[...] Dada a confusão aqui, isso é obviamente uma arma
A idéia geral de usar a configuração de shell para isso também parece funcionar, e. no login gráfico do Ubuntu Desktop 16.04. Há uma diferença, no entanto. O Fedora cria ~/.bash_profile por padrão, o que (por bash) faz com que ~/.profile seja ignorado. O Ubuntu e outras distribuições baseadas no Debian criam ~/.profile por 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. Ubuntu parece ter mudado ao longo do tempo para executar um shell de login para sessões GUI. Por exemplo, consulte link , link , "Por que o gnome-terminal não é um shell de login" , e "O que o login do shell significa ('bash -l')" ).