Diferença entre /etc/security/pam_env.conf e / etc / environment + fazendo o sudo ler o pam_env.conf

Question

Eu me esforço para ver a diferença entre pam_env.conf e /etc/environment . Para mim, ambos fazem a mesma coisa, com uma sintaxe diferente. As manpages não ajudaram. Então qual é a diferença?

Além disso, gostaria de encontrar uma maneira de adicionar caminhos à variável de ambiente PATH para todos os usuários. Adicioná-los aos dois arquivos acima mencionados funciona para todos os usuários, mas não funciona com o sudo, como pode ser verificado executando sudo sh -c 'echo $PATH' .

Para resolver esse problema, acredito que devo editar o arquivo /etc/pam.d/sudo , mas o que devo colocar lá?

    

Answer 1

Existem duas diferenças fundamentais entre /etc/security/pam_env.conf e /etc/environment .

1. A ordem em que o PAM os processa.

   /etc/environment é analisado primeiro, mas qualquer coisa definida aqui é substituída por definições para essas mesmas variáveis, se elas também existirem em pam_env.conf . No entanto, é possível subsumir + estender as variáveis de /etc/environment em /etc/security/pam_env.conf , por exemplo:

   /etc/security/pam_env.conf
   
   PATH   DEFAULT=${PATH}:/usr/sbin
   

2. Expansão variável

   a. /etc/environment não é um script, mas um conjunto de expressões de atribuição, por exemplo, ${PATH} não é expandido, mas usado literalmente.

   b. /etc/security/pam_env.conf é um animal completamente diferente. Não é um script por si só; ainda é apenas um conjunto de atribuições KEY = VALUE, mas o PAM pode expandir variáveis existentes (ex: ${PATH} , ${DISPLAY} ) e outros PAM_ITEMs (ex: @{PAM_SERVICE} , @{PAM_USER} , etc.). Tome nota especial de $ vs @ aqui.

   O PAM também lida com as variáveis especiais @{HOME} e @{SHELL} , que expandem para o que estiver definido em /etc/passwd . * Nota: na maioria dos aplicativos PAM, as variáveis tradicionais ${HOME} e ${SHELL} (compare @ vs $ ) não estão disponíveis tão cedo no fluxo do PAM.

   Usando o exemplo fornecido nos comentários de /etc/security/pam_env.conf , esse comportamento de substituição / expansão pode ser usado para modificar a variável DISPLAY para sessões de login remotas.

   /etc/security/pam_env.conf
   REMOTE_HOST     DEFAULT=localhost           OVERRIDE=@{PAM_RHOST}
   DISPLAY         DEFAULT=${REMOTE_HOST}:0.0  OVERRIDE=${DISPLAY}
   

Para o problema específico descrito aqui, os valores configurados em /etc/environment não estavam disponíveis no ambiente sudo temporary porque o recurso session fornecido pela definição do aplicativo PAM para /etc/pam.d/sudo nunca chama pam_env.so para sessões.

Em /etc/pam.d/sudo , as sessões importam apenas as regras de /etc/pam.d/system-auth . Seguindo a trilha, em /etc/pam.d/system-auth , a pilha de sessão não tem uma entrada para pam_env.so .

Existem algumas maneiras de personalizar as variáveis disponíveis em um ambiente sudo .

Se você precisar de um conjunto personalizado de variáveis de ambiente que existam apenas em sudo-land, é bastante simples.

1. Crie um arquivo para conter suas variáveis de ambiente exclusivas para o sudo.

   /etc/security/sudo_custom_vars.conf
   GREET   DEFAULT="hello from sudo land"
   VAR1    DEFAULT="${GREET}"
   _VAR2   DEFAULT="VAR2 not passed to sudo, ...but"
   VAR2    DEFAULT="${_VAR2} ${GREET}"                 OVERRIDE=${VAR2}
   VAR3    DEFAULT="Nope. Unknown users cannot sudo."  OVERRIDE=@{PAM_RUSER}
   ...
   

2. Faça uma cópia de /etc/pam.d/system-auth , renomeie-a para as linhas de /etc/pam.d/sudo-environment e adicione uma diretiva à parte inferior da pilha session :

   session     required    pam_unix.so
   session     optional    pam_permit.so
   # Add a line for using pam_env.so
   session     optional    pam_env.so conffile=/etc/security/sudo_custom_vars.conf
   

   Se você quiser passar variáveis do ambiente não-sudo, inclua o user_readenv=1 flag

   session     optional    pam_env.so      conffile=/etc/security/sudo_custom_vars.conf    user_readenv=1
   

3. Na definição do aplicativo PAM /etc/pam.d/sudo , faça a substituição:

   -   session    include       system-auth
   +   session    include       sudo-environment
   

4. Abra um novo terminal para testar

   $ su <your username>                    # Testing PAM without logging out
   $ export VAR1=""
   $ export VAR2="hello from down here"    # Set var in non-sudo environment
   
   $ echo $VAR1
   <nothing>
   $ sudo sh -c 'echo $VAR1'               # Test sudo's DEFAULT value
   hello from sudo land
   
   $ echo $VAR2
   hello from down here
   $ sudo sh -c 'echo $VAR2'               # VAR2 not passed to sudo
   VAR2 not passed to sudo, ...but hello from sudo land
   $ sudo -E su -c 'echo $VAR2'            # VAR2 (and everything else) passed to sudo
   hello from down here
   $ sudo env VAR2="inline override" su -c 'echo $VAR2'
   inline override
   
   $ sudo sh -c 'echo $VAR3'               # Testing we can read a PAM_ITEM
   aaron
   

Uma alternativa para mexer nos módulos PAM é editar /etc/sudoers com # visudo , como você fez. Eu percebo que esta é uma pergunta antiga e muito tempo atrás, comentando que Default env_reset era a coisa a fazer.

Avançando, a melhor prática aceita ao usar sudoers para extrair definições de variáveis do ambiente é anexar as variáveis a env_keep . (... isto é, a menos que você precise de um conjunto exclusivo de variáveis, conforme mostrado acima)

    /etc/sudoers
    Defaults env_keep += "var1 var2, etc..."

    

Answer 2

Consegui mais ou menos o que queria para o sudo:

Eu editei o arquivo /etc/sudoers (com sudo visudo ) e comentei as linhas Default env_reset e Default secure_path = ... .

Agora, o sudo usará o ambiente do usuário.

A diferença entre pam_env.conf e /etc/environment ainda não está clara para mim, então a pergunta ainda não foi respondida.