O arquivo de política tradicional do PAM é /etc/pam.conf
. Este arquivo contém todas as políticas do PAM para o seu sistema. Cada linha do arquivo descreve uma etapa em uma chain, conforme mostrado abaixo:
login auth required pam_nologin.so no_warn
Os campos estão, na ordem: nome do serviço, nome do recurso, flag de controle, nome do módulo e argumentos do módulo. Quaisquer campos adicionais são interpretados como argumentos adicionais do módulo.
Uma chain separada é construída para cada par de serviço/recurso, portanto, embora a ordem na qual as linhas para o mesmo serviço e recurso apareçam seja significativa, a ordem na qual os serviços e recursos individuais são listados não é. Os exemplos no artigo original do PAM agruparam as linhas de configuração por recurso, e o suporte do Solaris™ ao pam.conf
ainda faz isso, mas a configuração de ações do FreeBSD configura as linhas por serviço. De qualquer maneira está bem; De qualquer forma, faz o mesmo sentido.
O OpenPAM e o Linux-PAM suportam um mecanismo de configuração alternativo, que é o mecanismo preferido no FreeBSD. Neste esquema, cada política está contida em um arquivo separado com o nome do serviço ao qual se aplica. Esses arquivos são armazenados em /etc/pam.d/
.
Esses arquivos de políticas por serviço possuem apenas quatro campos, em vez de cinco no pam.conf
: o campo nome do serviço é omitido. Assim, em vez da linha de exemplo no pam.conf
da seção anterior, a seguinte linha deve estar em /etc/pam.d/login
:
auth required pam_nologin.so no_warn
Como consequência dessa sintaxe simplificada, é possível usar a mesma política para vários serviços vinculando cada nome de serviço a um mesmo arquivo de política. Por exemplo, para usar a mesma política para os serviços su
e sudo
, pode-se fazer o seguinte:
#
cd /etc/pam.d
#
ln -s su sudo
Isso funciona porque o nome do serviço é determinado a partir do nome do arquivo em vez de ser especificado no arquivo de políticas, portanto, o mesmo arquivo pode ser usado para vários serviços com nomes diferentes.
Como a política de cada serviço é armazenada em um arquivo separado, o mecanismo pam.d
também facilita a instalação de políticas adicionais para pacotes de software de terceiros.
Como explicado em Seção 4.1, “Arquivos de política do PAM”, cada linha em /etc/pam.conf
consiste em quatro ou mais campos: o nome do serviço, o nome do recurso, a flag de controle, o nome do módulo e nenhum ou mais argumentos do módulo.
O nome do serviço é geralmente (embora nem sempre) o nome do aplicativo ao qual a instrução se aplica. Se não tiver certeza, consulte a documentação do aplicativo individual para determinar qual nome de serviço ele usa.
Note que se você usar /etc/pam.d/
em vez de /etc/pam.conf
, o nome do serviço é especificado pelo nome do arquivo de política e omitido a partir das linhas de configuração atuais, que então começam com o nome da instalação.
O recurso é uma das quatro palavras-chave do recurso descritas em Seção 3.1, “Recursos e Primitivas”.
Da mesma forma, a flag de controle é uma das quatro palavras-chave descritas em Seção 3.3, “Cadeias e Políticas”, descrevendo como interpretar o código de retorno do módulo. O Linux-PAM suporta uma sintaxe alternativa que permite especificar a ação para associar com cada código de retorno possível, mas isso deve ser evitado, pois não é padrão e está intimamente ligado à forma como o Linux-PAM envia chamadas de serviço (que difere muito da maneira que Solaris™ e OpenPAM fazem isso). Não surpreendentemente, o OpenPAM não suporta esta sintaxe.
Para configurar o PAM corretamente, é essencial entender como as políticas são interpretadas.
Quando um aplicativo chama pam_start(3), a biblioteca PAM carrega a diretiva do serviço especificado e constrói quatro chains de módulos (uma para cada recurso). Se uma ou mais dessas chains estiverem vazias, as chains correspondentes da política para o outro
serviço são substituídas.
Quando o aplicativo chama mais tarde uma das seis primitivas PAM, a biblioteca PAM recupera a chain para o recurso correspondente e chama a função de serviço apropriado em cada módulo listado na chain, na ordem em que foram listadas na configuração. Após cada chamada para uma função de serviço, o tipo de módulo e o código de erro retornado pela função de serviço são usados para determinar o que acontece a seguir. Com algumas exceções, discutidas abaixo, a tabela a seguir se aplica:
PAM_SUCCESS | PAM_IGNORE | other | |
---|---|---|---|
binding | if (!fail) break; | - | fail = true; |
required | - | - | fail = true; |
requisite | - | - | fail = true; break; |
sufficient | if (!fail) break; | - | - |
optional | - | - | - |
Se fail
for true no final de uma chain, ou quando um “break” for atingido, o dispatcher retornará o código de erro retornado pelo primeiro módulo que falhou. Caso contrário, retorna PAM_SUCCESS
.
A primeira exceção é que o código de erro PAM_NEW_AUTHTOK_REQD
é tratado como um sucesso, exceto que se nenhum módulo falhar e pelo menos um módulo retornar PAM_NEW_AUTHTOK_REQD
, o dispatcher retornará PAM_NEW_AUTHTOK_REQD
.
A segunda exceção é que pam_setcred(3) trata os módulos binding
e sufficient
como se eles fossem required
.
A terceira e última exceção é que pam_chauthtok(3) executa a chain inteira duas vezes (uma vez para verificações preliminares e uma vez para definir a senha), e na fase preliminar, ele trata os módulos binding
e sufficient
como se fossem required
.
All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/
Questions that are not answered by the
documentation may be
sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.