newgrp e grupos atribuídos via pam_group.so

0

Por razões de conveniência, tenho a tendência de atribuir associações de grupo especiais como disquete, áudio, plugdev, vídeo etc. através do mecanismo /etc/security/group.conf (pam_group.so) em vez de adicionar todos os usuários a esses grupos no servidor de diretório. .

Isso funciona bem para o acesso ao dispositivo, mas tende a causar problemas quando programas externos tentam verificar a participação do usuário de um grupo específico por meio de getgrent.

Agora eu tentei newgrp para um desses grupos e reconheci que isso não é possível (o sistema é o Debian squeeze). Isso é um bug no newgrp ou apenas um problema de configuração no meu site?

O que o newgrp está realmente fazendo no lado da API do Unix? Parece que o setgid é uma chamada de sistema apenas de raiz. Eu teria pensado que seria permitido também se o usuário em particular fosse um membro do grupo alvo setgit.

Na verdade, eu tropecei no problema porque o mount.davfs continua me dizendo que eu não sou um membro do grupo davfs2, o que é claro, mas também é um grupo pam_group.so atribuído.

    
por Sven Geggus 21.06.2011 / 12:15

2 respostas

3

newgrp apenas dá acesso a um grupo ao qual você já tem acesso. Soa inútil? Basicamente sim. É principalmente uma sobra dos dias em que um processo não podia ser membro de vários grupos. Você também pode obter acesso a um grupo protegido por uma senha, mas isso é extremamente pouco usado.

Do ponto de vista do kernel, cada processo está em um ou mais grupos. setgid só pode ser usado quando rodando como root ou em programas setgid (para trocar entre os grupos real (run-by) e efetivo (run-as)). O kernel não sabe sobre bancos de dados de usuários e grupos.

Os bancos de dados de usuários e grupos ( /etc/passwd , /etc/group , /etc/security/group.conf , LDAP,…) são gerenciados por login , su e outros programas que gerenciam logins e elevação de privilégios, geralmente por meio do PAM. Ao efetuar login, você é atribuído aos grupos listados em /etc/passwd , /etc/group e outros arquivos por meio de pam_groups ; o processo se parece com isso:

gid_t groups[…] = /*extra GIDs computed from /etc/group and so on*/;
setgroups(sizeof(groups)/sizeof(gid_t), groups);
setgid(gid); /*main GID read from /etc/passwd*/
setuid(uid);
execve(shell, "-sh"); /*shell read from /etc/passwd*/

Em palavras: a renúncia aos privilégios de root (ou seja, a mudança para o usuário de destino) é feita após todos os outros gerenciamentos de privilégios, antes de invocar o shell do usuário. Depois que o processo não estiver mais sendo executado como root, não será possível obter grupos extras.

Se você acabou de adicionar um usuário a um grupo, ele entrará em vigor na próxima vez que o usuário fizer login. Se você iniciar outra sessão fazendo login em outro terminal ou por ssh, os processos nessa sessão terão o que quer que seja. grupos em que seu usuário estava no momento em que você efetuou login. É possível usar o comando groups ou id para ver em quais grupos você (ou seja, o processo específico do qual você iniciou groups ) é membro.

Então, eu respondi suas perguntas explícitas ( newgrp está fazendo o seu trabalho, o que não é o que você pensou). Eu posso ou não ter resolvido o seu problema. É incomum para aplicativos que não fazem logon para procurar bancos de dados de usuários e grupos; Normalmente, as permissões de acesso seriam decididas, verificando se o processo de solicitação é um membro do grupo relevante. Se você tiver algum problema com um aplicativo em particular, informe-nos.

    
por 21.06.2011 / 14:16
2

O motivo newgrp não pode mudar grupos em seus casos é que ele usa getgrent para determinar se você é um membro do grupo solicitado; ver função find_matching_group no arquivo de origem newgrp.c .

Por que o newgrp precisa executar esse cheque? Porque o conjunto de grupos em que um processo pertence (o chamado "vetor de grupo") é uma lista abritriada: o kernel não saber sobre /etc/group ou qualquer outro banco de dados do grupo e setgroups pode levar um lista arbitrária de grupos. Portanto, decidir quais grupos devem ser em um vetor de grupo de processo é uma questão de política : a política implementado pelo [newgrp] e pela maioria das outras ferramentas do espaço do usuário é ler o vetor de grupo via getgrent . ( A resposta de Gilles fornece detalhes sobre isso.)

Por outro lado, os pam_group implementam uma política diferente: pode aumentar o vetor de grupo com grupos dos quais um usuário não faz parte (de acordo com /etc/group ou LDAP).

Assim, no final, existem duas políticas diferentes e mount.davfs2 reclama porque assume que apenas a primeira está em vigor. Você provavelmente poderia relatar isso como um bug contra mount.davfs2 , ou apenas adicionar todos os usuários DAV ao grupo apropriado no LDAP ou /etc/group , ou usar um Sistema de arquivos DAV baseado em FUSE .

    
por 21.06.2011 / 16:21