Adicionei um usuário a um grupo, mas as permissões de grupo nos arquivos ainda não têm efeito

Question

Alterei as permissões de um arquivo ( chmod g+w testfile ) e execute ls -l testfile :

-rwxrwxr-x 1 user1 user1 0 2011-01-24 20:36 testfile

Em seguida, adicionei um usuário a esse grupo (" / etc / group " tem user1:x:1000:user2 line), mas não estou conseguindo editar esse arquivo como user2. Por que isso é assim?

    

Answer 1

user2 precisa sair e voltar. As permissões de grupo funcionam assim:

• Quando você faz login, seus processos podem ter associação de grupo no seu grupo principal mencionado em /etc/passwd , além de todos os grupos nos quais seu usuário é mencionado em /etc/group . (Mais precisamente, o campo pw_gid em getpw(your_uid) , mais todos os grupos dos quais seu usuário é um membro explícito Além de /etc/passwd e /etc/group , as informações podem vir de outros tipos de bancos de dados de usuários, como NIS ou LDAP. O grupo principal torna-se o processo ID de grupo eficaz e os outros grupos se tornam IDs de grupo suplementares .
• Quando um processo realiza uma operação que exige associação em um determinado grupo, como acesso a um arquivo , esse grupo deve ser o ID do grupo ou um dos IDs de grupo suplementares do processo.

Como você pode ver, sua alteração na participação no grupo do usuário só entra em vigor quando o usuário faz o login. Para os processos em execução, é tarde demais. Assim, o usuário precisa fazer logout e voltar. Se isso for demais, o usuário pode efetuar login em uma sessão separada (por exemplo, em um console diferente ou com ssh localhost ).

Sob o capô, um processo só pode perder privilégios (IDs de usuário, IDs de grupo, recursos). O kernel inicia o processo init (o primeiro processo após o boot) sendo executado como root, e todo processo é descendente desse processo¹. O login process (ou sshd , ou a parte do seu gerenciador de área de trabalho que faz o seu login) ainda está sendo executado como root. Parte de seu trabalho é descartar os privilégios de root e mudar para o usuário e grupos adequados.

Existe uma única exceção: executar um programa setuid ou setgid . Esse programa recebe permissões adicionais: ele pode optar por atuar sob vários subconjuntos das associações do processo pai, além da associação adicional no usuário ou grupo que possui o executável setxid. Em particular, um programa de raiz setuid tem permissões de root, portanto, pode fazer tudo²; é assim que programas como su e sudo podem fazer seu trabalho.

_{Ocasionalmente, existem processos que não são derivados de init (initrd, udev), mas o princípio é o mesmo: inicie como root e perca os privilégios ao longo do tempo.}
² _{Bloqueio de estruturas de segurança multinível, como o SELinux.}

    

Answer 2

Pode ser necessário que o usuário2 efetue logout e login novamente (ou apenas tente ssh'ing para criar uma nova sessão de login). Verifique a saída de id --groups para mostrar os IDs de grupos numéricos para um usuário.

    

Answer 3

sudo su $(whoami)

Essencialmente a mesma solução alternativa que ssh localhost , mas utilizável sem ter um servidor ssh instalado.

Contanto que você tenha raiz. Mas se você acabou de adicionar um novo grupo & permissões alteradas, você provavelmente faz.

    

Answer 4

Há um caso em que o logout do usuário não ajuda - se você estiver usando a diretiva ssh do ControlMaster para o host. Se você adicionar sua conta a um grupo, faça logoff e faça logon novamente na mesma conexão do ControlMaster, a sessão ainda não mostrará nenhuma nova associação. Você terá que forçar a quebra da conexão Mestre com

ssh -O exit hostname

antes de fazer o login novamente.