Artigos 13 mar 2007 05:29 pm
Autenticação Centralizada com Postgres – NSS e PAM
A rede da empresa em que trabalho já há muito tempo autentica os usuários em um banco de dados Mysql, no entanto devido ao processo de migração de nosso sistema interno, decidimos que o PostgreSQL será o banco oficial com que iremos trabalhar e portanto nosso banco de usuários deveria ser migrado para o mesmo.
Como eu já havia visto algumas poucas coisas a respeito de autenticação de usuários com Postgres na época em que configurei a autenticação com Mysql, imaginei que hoje em dia o suporte ao PostgreSQL estaria melhor e disponível em uma variedade maior de softwares, o que pra minha alegria é uma verdade.
Com o objetivo de centralizar a maior quantidade de sistemas de autenticação disponíveis na rede, comecei a pesquisar a respeito do assunto.
Nesse primeiro artigo exemplifico a configuração da libnss e do pam em conjunto com o PostgreSQL.
Futuramente publicarei também a minha experiência com o Samba, Postfix e outros serviços disponíveis na rede que administro.
NSS e PAM
Nos sistemas operacionais Linux e outros derivados do Unix é comum utilizar o NSS (Name Service Switch) em conjunto com o PAM para cuidar da autenticação dos usuários e do permissionamento no acesso a arquivos/diretórios.
Ao realizar a configuração da rede para autenticar via banco Mysql há alguns anos atrás não me preocupei em entender a diferença entre NSS e PAM, e portanto somente realizei a configuração da libnss. Hoje, ao pesquisar sobre essa integração com o PostgreSQL acabei por me deparar com o pam-pgsql que me forçou entender principalmente a diferença entre NSS e PAM e as vantajens de configurar também o PAM.
NSS
O NSS tem por objetivo prover bancos de dados para substituir ou adicionar informações aos arquivos Unix tradicionais (passwd, shadow, group, hosts, e outros). Os programas que desejam verificar informações em tais bancos utilizam funções padrões da glibc como por exemplo getpwent para recuperar informações sobre uma conta de usuário.
Programas como ls, e id por exemplo verificam as informações do usuário via funções da glibc que por sua vez busca as informações via libnss.
PAM
O PAM (Pluggable Authentication Module) por sua vez, como o próprio nome diz tem como principal objetivo prover uma interface comum e modular para autenticação de usuários a qualquer serviço que utilize suas chamadas de função. Processos como login, e su por exemplo utilizam o PAM para autenticar o usuário.
É claro que o PAM não fica limitado a autenticação e também pode ser utilizado para trocar a senha do usuário ou para limitar os recursos da máquina utilizados pelo mesmo, e a cada dia mais módulos surgem para ele tornando seu uso mais abrangente e talvez até um pouco fora do contexto original.
E agora, qual usar?
É possível utilizar tanto a libnss-pgsql quanto o pam-pgsql no sistema de modo a centralizar as informações dos usuários, no entanto vale observar que cada um exerce uma função diferente.
Como já vimos anteriormente, o NSS exerce funções diferentes do PAM e apesar de que alguns processos possam utilizá-lo diretamente para autenticar usuários, sua função principal é de verificar as permissões de acesso dos usuários/grupos e portanto seu uso é obrigatório quando o usuário vem de um banco de dados.
Hoje em dia algumas distribuições utilizam uma variação do módulo pam_unix geralmente chamado de pam_unix2 (responsável pela autenticação via arquivos Unix tradicionais), fazendo com que o mesmo utilize a libnss disponível no sistema para realizar os processos de autenticação.
Caso sua distribuição (como a RedHat, Suse ou Gentoo) utilize essa variação do pam_unix, pode ser suficiente utilizar apenas a libnss e deixar o PAM com sua configuração padrão.
NSS
Instalação
A instalação do libnss-pgsql é rápida e fácil e exige que a biblioteca libpq (versão 7.4 ou superior) esteja instalada no sistema. Usuários do gentoo terão as dependências resolvidas com:
# emerge libnss-pgsql
Como a máquina de teste utiliza arquitetura 64 bits e o ebuild só está disponível para arquiteturas x86 é necessário enganar o portage para conseguir compilar o pacote, isso pode ser feito adicionando uma linha ao arquivo package.keywords:
# echo “sys-auth/libnss-pgsql ~x86″ >> /etc/portage/package.keywords
Usuários de outras distribuições podem fazer o download do tarball dos fontes no site do PgFoundry em conjunto com o famoso trio de comandos ./configure, make e make install.
Modelagem dos dados
O primeiro passo a ser tomado é a modelagem dos dados (estruturação do banco). Para o funcionamento do sistema é necessário um mínimo de 3 tabelas sendo 1 para armazenar os usuários (/etc/passwd), outra para os grupos (/etc/group) e 1 de relacionamento entre os usuários e os grupos.
A instalação do libnss-psql dispõe de um arquivo de exemplo com as tabelas a serem criadas em /usr/share/doc/libnss-pgsql-x.y.z/examples/dbschema.sql (onde x.y.z representa a versão do pacote).
Apesar do exemplo de instalação recomendar o uso de uma tabela separada para armazenar a senha e outras informações da conta (/etc/shadow), seu uso não é obrigatório e as informações extras do shadow podem ser adicionadas na tabela de usuários (passwd). Nesse caso para aumentar a segurança e também para utilizar recursos extras do PAM será criada uma tabela para armazenar os dados do arquivo shadow
A estrutura de tabelas utilizada nesse artigo foi feita para atender as necessidades da minha rede e pode ser modificada conforme a necessidade.
Antes de mais nada é necessário criar o usuário que terá acesso ao banco. Isso pode ser feito com o comando # createuser -P db. Em seguida, caso o banco de dados ainda não exista é necessário criá-lo com o comando # createdb -O db -E UTF8 db.
Em seguida conecte-se ao banco e execute a query a seguir:
CREATE SEQUENCE grupo_gid MINVALUE 3000 MAXVALUE 2147483647 NO CYCLE;
CREATE SEQUENCE usuario_uid MINVALUE 3000 MAXVALUE 2147483647 NO CYCLE;
CREATE TABLE "usuarios" (
"login" character varying(64) NOT NULL,
"senha" character varying(128) NOT NULL,
"uid" int4 NOT NULL DEFAULT nextval('usuario_uid'),
"gid" int4 NOT NULL,
"desc" character varying(128),
"homedir" character varying(256) NOT NULL,
"shell" character varying DEFAULT '/bin/bash' NOT NULL,
PRIMARY KEY ("login"),
UNIQUE ("uid")
);
CREATE TABLE "grupos" (
"gid" int4 NOT NULL DEFAULT nextval('grupo_gid'),
"nome" character varying(16) NOT NULL,
"desc" character varying,
"senha" character varying(20),
PRIMARY KEY ("gid"),
UNIQUE ("gid")
);
CREATE TABLE "usuarios_grupos" (
"gid" int4 NOT NULL,
"uid" int4 NOT NULL,
PRIMARY KEY ("gid", "uid"),
CONSTRAINT "ug_gid_fkey" FOREIGN KEY ("gid") REFERENCES "grupos"("gid"),
CONSTRAINT "ug_uid_fkey" FOREIGN KEY ("uid") REFERENCES "usuarios"("uid")
);
CREATE TABLE "senhas"
(
"uid" int4 NOT NULL,
"senha" character varying(128) NOT NULL,
"ts_atualizacao" TIMESTAMP with time zone NOT NULL DEFAULT now(),
"min_dias_atualizar" int4 NOT NULL DEFAULT 0,
"max_dias_atualizar" int4 NOT NULL DEFAULT 30,
"dias_antes_expirar" int4 NOT NULL DEFAULT 7,
"dias_desabilitar" int4 NOT NULL DEFAULT 7,
"ts_desabilitar" TIMESTAMP with time zone NOT NULL DEFAULT now()+'1 year',
PRIMARY KEY ("uid"),
UNIQUE ("uid")
);
Após criadas as tabelas é necessário inserir alguns dados de teste no banco:
INSERT INTO grupos (nome) values ('myers');
INSERT INTO grupos (nome) values ('outro_grupo');
INSERT INTO usuarios (login, senha, homedir, gid,uid)
VALUES ('myers','x','/home/myers',3000,1002);
INSERT INTO grupos_usuarios(3001,1002);
INSERT INTO senhas (uid,senha) VALUES (1002,md5('teste'));
Os gids 3000 e 3001 são gerados automaticamente ao inserir dados na tabela de grupos. O uid 1002 é utilizado por motivo de compatibilidade com a instalação da máquina de testes e seria gerado automaticamente caso não fosse especificado.
A senha “x” define que a senha deve ser verificada no arquivo shadow (ou tabela equivalente)).
Configuração
Passwd e Group
A configuração da libnss-pgsql não tem muitos mistérios e se resume em editar 3 arquivos de configuração. Primeiramente é necessário editar o arquivo /etc/nss-pgsql.conf, que armazena as informações rerentes aos arquivos passwd e group. Um arquivo de exemplo é fornecido com a instalação e pode ser encontrado no diretório de documentos da biblioteca (/usr/share/doc/libnss-pgsql-x.y.z/examples/).
Nesse arquivo são definidas as consultas (sql) e a conexão ao banco. O arquivo de exemplo vem com uma consulta para o método getgroupmembersbygid que verifica apenas os grupos efetivos na tabela de usuários. Sendo assim alterei a consulta para verificar na tabela usuarios_grupos de modo a retornar todos os usuários de um dado grupo.
É recomendável criar um segundo usuário para o banco, sendo que esse novo usuário deve ter acesso somente de leitura (“SELECT”) nas tabelas “usuarios”, “grupos” e “usuarios_grupos” uma vez que o arquivo de configuração deve ter permissão de leitura global e portanto a senha do banco estará disponível a todos.
# createuser -P db_nss
Em seguida conecte-se ao banco usando o usuário que criou o banco (db) e execute as seguintes querys:
GRANT SELECT ON TABLE usuarios TO db_nss;
GRANT SELECT ON TABLE grupos TO db_nss;
GRANT SELECT ON TABLE usuarios_grupos TO db_nss;
Após criado o usuário edite o arquivo d econfiguração /etc/nss-pgsql.conf
(Conexão com banco de dados)
connectionstring = hostaddr=localhost dbname=db user=db_nss password=xxx connect_timeout=1
(Retorna os dados do usuário de acordo com o login especificado)
getpwnam = SELECT login, senha, ‘desc’ AS gecos, homedir, shell, uid, gid FROM usuarios WHERE login=$1
(Retorna os dados do usuário de acordo com o uid especificado)
getpwuid = SELECT login, senha, ‘desc’ AS gecos, homedir, shell, uid, gid FROM usuarios WHERE uid=$1
(Retorna os dados de todos os usuários)
allusers = SELECT login, senha, ‘desc’ AS gecos, homedir, shell, uid, gid FROM usuarios
(Retorna os dados do grupo de acordo com o nome de grupo especificado)
getgrnam = SELECT nome, senha, gid FROM grupos WHERE nome=$1
(Retorna os dados do grupo de acordo com o gid especificado)
getgrgid = SELECT nome, senha, gid FROM grupos WHERE gid=$1
(Retorna os dados de todos os grupos)
allgroups = SELECT nome, senha, gid FROM grupos
(Retorna todos os grupos que o usuário pertence exceto o grupo primário)
groups_dyn = SELECT g.gid FROM usuarios JOIN grupos g USING (uid) where login = $1 and g.gid <> $2
(Retorna todos os usuários de um grupo de acordo com o gid especificado)
getgroupmembersbygid = SELECT login FROM usuarios JOIN usuarios_grupos g USING (uid) where g.gid = $1
Shadow
O arquivo /etc/nss-pgsql-root.conf por sua vez armazena as informações referentes ao shadow e apesar de não ser obrigatório existir uma tabela específica para o shadow, seu arquivo de configuração deve ser criado caso deseje utilizar informações extras como por exemplo data de expiração da conta (informações referentes a idade da conta só estão disponíveis no shadow).
Para que o usuário seja verificado na tabela referente ao shadow é necessário retornar a senha como “x” (x minúsculo) no arquivo shadow.
Caso nenhuma informação de idade da conta seja necessária, é possível retornar valores estáticos na consulta a tabela de senhas como com a query SELECT login, senha, ’1′, ’0′, ’99999′, ’0′, ’0′, ‘-1′,’0′.
Caso as informações de idade da conta sejam necessárias é necessário retorná-las no formato do shadow (número de dias após 01/01/1970). Para facilitar uma view pode ser criada para retornar esses dados. Execute a query a seguir para criar a view no banco.
CREATE VIEW "shadow" AS (
SELECT
login,
s.senha,
DATE_PART('DAYS', ts_atualizacao-'1970-01-01') AS ts_atualizacao,
min_dias_atualizar,
max_dias_atualizar,
dias_antes_expirar,
dias_desabilitar,
DATE_PART('DAYS', ts_desabilitar-'1970-01-01') AS ts_desabilitar
FROM
senhas AS s
JOIN
usuarios USING(uid)
);
Após criada a view, edite o arquivo /etc/nss-pgsql-root.conf conforme exemplo e informe o usuário/senha do banco com permissão de leitura da tabela “senhas”. Como esse arquivo deve ser protegido para acesso somente do root (# chmod 640 /etc/nss-pgsql-root.conf) o usuário do banco utilizado pode ter mais privilégios pois sua senha não serã visível a todos.
(Conexão com banco de dados) shadowconnectionstring = hostaddr=127.0.0.1 dbname=db user=db password=db connect_timeout=1 #Query in the following format (Retorna os dados do usuário especificado) shadowbyname = SELECT login, senha, ts_atualizacao, min_dias_atualizar, max_dias_atualizar, dias_antes_expirar, dias_desabilitar, ts_desabilitar, '0' FROM shadow WHERE login = $1 (Retorna os dados de todos os usuários) shadow = SELECT login, senha, ts_atualizacao, min_dias_atualizar, max_dias_atualizar, dias_antes_expirar, dias_desabilitar, ts_desabilitar, '0' FROM shadow
nsswitch
Por último, é necessário alterar o arquivo /etc/nsswitch.conf de modo que as consultas de usuário/grupos sejam feitas no banco Postgres em adição aos arquivo passwd, group e shadow.
As páginas de manual do arquivo nsswitch.conf explicam melhor o seu formato e as várias opções de configuração disponíveis, no entanto para uma configuração simples de autenticação basta adicionar a palavra-chave pgsql em cada linha referente aos arquivos mantidos pelo banco conforme o exemplo:
passwd: files pgsql
shadow: files pgsql
group: files pgsql
É absolutamente recomendado manter um editor aberto com permissões de root com o arquivo /etc/nsswitch.conf para desfazer as alterações caso algo dê errado pois configurações erradas nesse arquivo podem impedir o login na máquina.
Testes
Testar o sistema é bem simples e pode ser feito tentando logar na máquina ou utilizando o comando id para verificar por exemplo os grupos em que determinado usuário está associado.
É possível por exemplo mixar as informações do /etc/group com as tabelas do banco de dados para por exemplo adicionar o usuário vindo do banco em grupos só disponíveis na máquina local (no grupo wheel por exemplo).
# id myers
uid=1002(myers) gid=3000(myers) groups=3000(myers),10(wheel),3001(outro_grupo)
No exemplo acima o usuário foi adicionado ao grupo wheel através do arquivo /etc/group embora nesse caso tal ação tenha que ser feita manualmente pois com o uso da libnss-pgsql os comandos de gerenciamento de usuários/grupos perdem seu efeito para os usuários vindos do banco.
Resolução de Bugs
A versão 1.4.0 da libnss-pgsql vêm de fábrica com um bug que faz com que a resolução de usuários/grupos entre em loop caso o banco de dados esteja inacessível, isso pode ser bem perigoso para uma máquina em produção uma vez que se um processo do root por exemplo tentar fazer o lookup das informações do usuário, o processo vai entrar em loop e o load da máquina começará a subir consideravelmente. Apesar do bug já estar documentado desde o meio de 2006, por algum motivo ainda não foi liberada nenhuma nova versão com o bug corrigido.
Abaixo segue patch de correção que fiz de acordo com as informações sobre o problema que encontrei na internet.
--- libnss-pgsql-1.4.0/src/interface.c 2007-03-13 17:51:04.000000000 -0300
+++ /tmp/interface.c 2007-03-13 17:51:24.000000000 -0300
@@ -114,7 +114,7 @@
}
__libc_lock_unlock(lock);
- return NSS_STATUS_SUCCESS;
+ return retval;
}
enum nss_status
Ou faça o download do patch e do ebuild e salve no diretório do portage local (portage dir overlay):
# mkdir -p /usr/local/portage/sys-auth/
# /usr/local/portage/sys-auth/
# cp -a /usr/porta/sys-auth/libnss-pgsql . ( ponto )
# cd libnss-pgsql/files
# wget http://www.claudineimatos.com/files/libnss-pgsql/libnss-pgsql-1.4.0-setgrent_fixed.patch
# cd ..
# wget http://www.claudineimatos.com/files/libnss-pgsql/libnss-pgsql-1.4.0.ebuild
# ebuild libnss-pgsql-1.4.0.ebuild manifest
Após criados os diretórios e copiados os aquivos, é necessário adicionar uma linha no arquivo /etc/make.conf para que o portage saiba onde procurar por um repositório customizado:
# vi /etc/make.conf
PORTDIR_OVERLAY="/usr/local/portage"
Uma vez feito isso instale normalmente a biblioteca com # emerge libnss-pgsql.
Para voltar a utilizar as versões providas árvore oficial do portage, comente ou remova a linha no arquivo make.conf.
PAM
Atualmente existem 2 projetos diferentes do pam-pgsql, sendo que um deles pode ser encontrado no sourceforge e está na versão 0.6.3 e o outro está disponível no pgfoundry assim como a libnss-pgsql e está na versão 1.0.
A versão 1.0 do pgfoundry é baseada na versão 0.5 disponível no sourceforge e apesar de parecer mais recente, seu último release é quase 1 ano mais antigo que a versão disponível no sourceforge. Sendo assim será utilizada a versão 0.6.3 encontrada no sourceforge.
Instalação
A instalação do pam-pgsql não é muito complicada e exige que esteja instalada a biblioteca libpq (versão 7.4 ou superior) e a libmhash.
Apesar do pam-pgsql não estar disponível ainda na árvore do portage, é possível utilizar o ebuild disponível no bugzilla do gentoo ou o ebuild que disponibilizo aqui no site.
A versão 0.6.3 quando compilada com a gcc 4.0 ou superior alerta sobre alguns métodos incorretos de programação (na verdade são alterações do tipo da variável) que podem ser suprimidos se a gcc for executada com -fno-strict-aliasing. Um patch está disponível aqui no site para ser usado em conjunto com o ebuild.
Usuários do gentoo podem baixar o ebuild, o patch e o arquivo de configuração de exemplo no diretório overlay do portage (previamente criado).
# mkdir -p /usr/local/portage/sys-auth/pam-pgsql/files
# cd /usr/local/portage/sys-auth/pam-pgsql/files
# wget http://www.claudineimatos.com/files/pam-pgsql/pam-pgsql-0.6.3-no_strict_aliasing.patch
# wget http://www.claudineimatos.com/files/pam-pgsql/pam_pgsql.conf
# cd ..
# wget http://www.claudineimatos.com/files/pam-pgsql/pam-pgsql-0.6.3.ebuild
# ebuild ebuild digest
# emerge pam-pgsql
Usuários de outras distribuições podem fazer o download do tarball dos fontes no site da Libmhash e do pam-pgsql e utilizar o famoso trio de comandos ./configure, make e make install.
É necessário informar ao portage onde encontrar o diretório overlay adicionando a variável PORTDIR_OVERLAY="/usr/local/portage" no arquivo /etc/make.conf
Configuração
A configuração do pam-pgsql assim como a libnss-pgsql é simples no entanto é necessário prestar muita atenção nos arquivos editados pois um erro pode tornar impossível logar novamente no sistema.
Como o pam-pgsql também fará alteração no banco (para alterar a senha por exemplo), é necessário que o usuário de acesso ao banco tenha tais permissões e como já dito anteriormente é altamente recomendável usar um usuário separado para tais fins.
O arquivo /etc/pam_pgsql.conf armazena as configurações do módulo e seu formato é parecido com a configuração da libnss-pgsql. O ebuild disponível aqui no site instala um exemplo do arquivo de configuração em (/usr/share/doc/pam-pgsql-x.y.z/examples/).
Para tornar o sistema mais prático e funcional é possível utilizar alguns recursos do PostgreSQL como triggers para que ao alterar a senha do usuário, a data de alteração da senha seja definida para a data atual. Execute a query a seguir para criar a trigger e associála a tabela “senhas”.
CREATE FUNCTION senhaAlterada() returns trigger as $$
begin
if NEW.senha != OLD.senha then
UPDATE senhas SET ts_atualizacao=CURRENT_TIMESTAMP WHERE uid=OLD.uid;
end if;
return NEW;
end;
$$ language plpgsql;
CREATE TRIGGER trg_senha AFTER UPDATE ON senhas
for each row execute procedure senhaAlterada();
Pode ser necessário criar o suporte a linguagem plpgsql, isso pode ser feito executando createlang plpgsql db como o usuário postgres
Como o PAM nos permite ir além da autenticação básica e a biblioteca pam-pgsql fornece outras informações como por exemplo o serviço que está consultando a base, é possíver ir além e criar mecanismos extras para a autenticação. Duas tabelas são necessárias para realizar esse controle e assim definir quais serviços (login, passwd, sshd, etc) o usuário pode usar. Execute a query a seguir para criar as tabelas.
CREATE SEQUENCE servico_sid MINVALUE 1 MAXVALUE 2147483647 NO CYCLE;
CREATE TABLE "servicos"
(
"sid" int4 NOT NULL DEFAULT nextval('servico_sid'),
"nome" character varying(64) NOT NULL,
"descricao" character varying(128) NOT NULL,
PRIMARY KEY ("nome"),
UNIQUE ("sid"),
UNIQUE ("nome")
);
CREATE TABLE "usuarios_servicos"
(
"sid" int4 NOT NULL,
"uid" int4 NOT NULL,
PRIMARY KEY ("sid", "uid"),
CONSTRAINT "us_sid_fkey" FOREIGN KEY ("sid") REFERENCES "servicos"("sid"),
CONSTRAINT "us_uid_fkey" FOREIGN KEY ("uid") REFERENCES "usuarios"("uid")
);
As consultas realizadas pelo pam devem retornar 4 informações sendo elas: senha, true ou false se a conta estiver expirada, true ou false se a senha estiver expirada e true ou false se a senha for nula. Para facilitar as coisas mais uma view deve ser criada. Execute a query a seguir para criar a view.
CREATE VIEW "pam_shadow" AS(
SELECT
login,
s.senha,
uid,
srv.nome AS servico,
CASE
WHEN now() >= ts_atualizacao+(dias_desabilitar+max_dias_atualizar||' days')::interval
OR now() >= ts_desabilitar THEN 1::integer
ELSE 0::integer
END AS conta_expirada,
CASE
WHEN now() >= ts_atualizacao+(max_dias_atualizar||' days')::interval THEN 1::integer
ELSE 0::integer
END AS senha_expirada,
CASE
WHEN s.senha IS NULL OR s.senha = '' THEN 1::integer
ELSE 0::integer
END AS senha_nula
FROM
senhas AS s
JOIN usuarios USING(uid)
JOIN usuarios_servicos AS us USING(uid)
JOIN servicos AS srv USING(sid)
);
Em seguida edite o arquivo de configuração /etc/pam_pgsql.conf conforme o exemplo:
(Conexão com banco de dados)
connect = dbname=db user=db password=db connect_timeout=15
(Retorna a senha do usuário especificado)
auth_query = SELECT senha FROM pam_shadow WHERE login = %u AND servico=%s
(Retorna informações sobre a senha em formato booleano: senha expirada, requisitar nova senha e senha nula. Esses campos não são obrigatórios e podem ter seu valor fixo caso não utilizados. )
acct_query = SELECT conta_expirada, senha_expirada, senha_nula FROM pam_shadow WHERE login = %u AND servico=%s
(Atualiza a senha do usuário especificado)
pwd_query = UPDATE senhas SET senha = %p WHERE uid=(SELECT uid FROM pam_shadow WHERE login= %u AND servico=%s)
(Utiliza senhas no formato crypt com md5)
pw_type = crypt_md5
(Imprime mensagens de debug no syslog)
debug
Assim como com o arquivo referente ao shadow, é altamente recomendável alterar as permissões do arquivo pam-pgsql.conf deixando-o legível somente ao root com o comando # chmod 640 /etc/pam-pgsql.conf principalmente se o usuário especificado do banco tiver permissão de alteração nas tabelas.
Após configurado o módulo, é necessário configurar o PAM para utilizar o novo módulo em seus processos de autenticação. No gentoo assim como em outras distribuições o arquivo do PAM responsável pela autenticação é o /etc/pam.d/system-auth.
A alteração a ser feita no arquivo é relativamente simples e basicamente se resume em adicionar linhas referentes ao novo módulo e alterar algumas outras referentes ao pam_unix.
Embora o conteúdo desse arquivo possa variar de uma distribuição pra outra, geralmente ele costuma ser bem similar em suas variações. O arquivo padrão do gentoo é o que segue:
auth required pam_env.so
auth sufficient pam_unix.so likeauth nullok
auth required pam_deny.so
account required pam_unix.so
password required pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3
password sufficient pam_unix.so nullok md5 shadow use_authtok
password required pam_deny.so
session required pam_limits.so
session required pam_unix.so
Ele deve ser alterado para parecer com o seguinte:
auth required pam_env.so auth sufficient pam_pgsql.so # linha nova auth sufficient pam_unix.so likeauth nullok use_first_pass # linha modificada auth required pam_deny.so account sufficient pam_pgsql.so # linha nova account sufficient pam_unix.so # linha modificada account required pam_deny.so # linha nova password required pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3 password sufficient pam_unix.so nullok md5 shadow use_authtok # linha modificada password sufficient pam_pgsql.so use_first_pass # linha nova password required pam_deny.so session required pam_limits.so session required pam_unix.so
Testes
Após tudo configurado é possível por exemplo alterar a senha usando o comando passwd ou mesmo fazer um login no sistema e verificar no syslog as linhas referentes ao pam_pgsql caso o debug esteja habilitado.
Também é possível configurar outros serviços que se utilizem do PAM para utilizar o pam_pgsql na autenticação.
Vale lembrar que como agora existem 2 módulos a serem verificados para a autenticação do usuário, eles serão usados na ordem em que são inseridos ou seja, no caso acima a configuração verificará o usuário primeiramente no Postgres e só depois na libnss (que retornará ao Postgres) ou nos arquivos tradicionais. Um exemplo disso é que na hora de logar como root a senha será requisitada 2 vezes dando erro na primeira tentativa a menos que o root também esteja cadastrado no banco de dados, o que não é recomendável.
Referências
- man nsswitch.conf
- man 5 shadow
- man 5 passwd
- man pam
- zless /usr/share/doc/pam-x.x.x/modules/README.pam_unix.gz
- Debian Bug Report logs
- libnss-pgsql
- Documentation NSS / PAM /MYSQL
Posts Relacionados:
Related posts brought to you by Yet Another Related Posts Plugin.