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

Mudei as permissões de um arquivo ( chmod g+w testfile) e a execução ls -l testfilefornece:

-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:user2linha), mas não consigo editar esse arquivo como usuário2. Porque isto é assim?

user2 precisa fazer logoff e logon novamente. As permissões de grupo funcionam da seguinte maneira:

• Quando você faz login, seus processos passam a ter participação no grupo principal mencionado /etc/passwd, além de todos os grupos nos quais o usuário é mencionado /etc/group. (Mais precisamente, o pw_gidcampo getpw(your_uid), além de todos os grupos dos quais o usuário é um membro explícito . Beyond /etc/passwde /etc/group, as informações podem vir de outros tipos de bancos de dados do usuário, como NIS ou LDAP). O grupo principal se torna o processo de ID de grupo efetiva e os outros grupos se tornam seus IDs de grupo suplementares .
• Quando um processo executa uma operação que requer associação a um determinado grupo, como acessar um arquivo , esse grupo deve ser o ID do grupo efetivo ou um dos IDs de grupo suplementares do processo.

Como você pode ver, sua alteração na associação ao grupo do usuário só entra em vigor quando o usuário efetua login. Para processos em execução, é tarde demais. Portanto, o usuário precisa fazer logoff e logon novamente. Se houver muitos problemas, o usuário poderá 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 initprocesso (o primeiro processo após a inicialização) sendo executado como root, e todo processo é descendente desse processo¹. O loginprocesso (ou sshdparte do seu gerenciador de área de trabalho que você efetua login) ainda está sendo executado como root. Parte de seu trabalho é eliminar os privilégios de root e mudar para o usuário e grupos adequados.

Há uma única exceção: executar um programa setuid ou setgid . Esse programa recebe permissões adicionais: pode optar por atuar em vários subconjuntos de 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 raiz setuid possui permissões de raiz, portanto, pode fazer tudo²; é assim que os programas gostam sue sudopodem fazer seu trabalho.

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

Pode ser necessário que o usuário2 efetue logoff e logon novamente (ou tente ssh'ing para criar uma nova sessão de logon). Verifique a saída de id --groupspara mostrar os IDs de grupo numérico de um usuário.

sudo su $(whoami)

Essencialmente, a mesma solução alternativa ssh localhost, mas utilizável sem a instalação de um servidor ssh.

Contanto que você tenha raiz. Mas se você acabou de adicionar um novo grupo e alterar as permissões, provavelmente o fará.

Há um caso em que o logout do usuário não ajuda - se você estiver usando a diretiva ControlMaster ssh para o host. Se você adicionar sua conta a um grupo, efetuar logoff e logon novamente na mesma conexão do ControlMaster, a sessão continuará mostrando a você nenhuma nova associação. Você terá que interromper à força a conexão Master com

ssh -O exit hostname

antes de fazer logon novamente.