Implicações de adicionar manualmente um usuário ao grupo de funcionários

Question

Isso surgiu como um problema de permissão no Ubuntu 16.04. Não consegui remover algumas bibliotecas R instaladas em /usr/local/lib/R/site-library . Acontece que eu não tinha permissão. O diretório era de propriedade de root e o grupo era staff .

Resolvi temporariamente o problema de permissão adicionando manualmente meu usuário ao grupo staff .

sudo usermod -a -G staff myusername    

# *see blockquote before using this!* 

Isso me permite remover as bibliotecas do IDE.

No entanto, quando tentei procurar mais informações sobre o grupo de funcionários e não consegui encontrar nenhum material definido sobre o assunto. Nem mesmo para o que o grupo foi destinado principalmente. Eu só podia imaginar que ele é usado para dar acesso "aprimorado" a usuários em determinados diretórios.

Existe alguma implicação de adicionar manualmente um usuário ao grupo de funcionários?

Como um aparte, existe algum comando para saber as permissões do sistema para um grupo? Por exemplo, quais são todos os diretórios para os quais a equipe do grupo terá permissão de gravação?

Obrigado.

  

Edit: Eu devo adicionar aqui que usar adduser em vez de usermod é uma opção muito mais sensata para esta operação [por favor, veja o comentário abaixo]

     

sudo adduser myusername staff

    

Answer 1

Ok, como cutucado por @muru , estou postando uma resposta para a minha própria pergunta, na medida em que eu posso. O arquivo file:///usr/share/doc/base-passwd/users-and-groups.html inclui informações detalhadas sobre grupos e permissões. Um espelho desta página pode ser encontrado aqui: Usuários e Grupos

Assim:

  

equipe

     

Permite que os usuários adicionem modificações locais ao sistema ( /usr/local , /home ) sem precisar de privilégios de root. Compare com o grupo adm , que está mais relacionado ao monitoramento / segurança.

     

Observe que a capacidade de modificar /usr/local é efetivamente equivalente ao acesso raiz (pois /usr/local está intencionalmente em caminhos de pesquisa à frente de /usr ) e, portanto, você só deve adicionar usuários confiáveis a esse grupo. Seja cuidadoso em ambientes que usam o NFS, pois a aquisição de privilégios de outros usuários não-root geralmente é mais fácil em tais ambientes.

É claro que o adm já está no meu groups , então posso fazer dmesg . Mas eu tive que me adicionar manualmente ao staff

O registro de uma lista de diretórios pertencentes à equipe mostra que todos eles pertencem a um destes:

sudo find / -maxdepth 8 -type d -group staff -perm -g=w >>stafflog.txt

/var/local
/usr/local/lib
/usr/local/share

Não admira que a associação de funcionários me dê acesso de gravação às minhas bibliotecas de linguagem de programação compartilhada.

verificando permissão para um destes:

ls -al /var/local

drwxrwsr-x  2 root staff 4096 Apr 11  2014 .
drwxr-xr-x 16 root root  4096 Aug  3 15:55 ..

Então, aparentemente, o truque da equipe é executado pelo sistema, definindo o bit dos diretórios ( setguid ). , para que qualquer usuário ou processo crie os arquivos nesse diretório, o arquivo sempre será executado com as permissões compartilhadas entre o grupo de funcionários. Veja aqui

No entanto, ainda me pergunto se posso me manter seguramente neste grupo. Na minha opinião, deve ser bastante seguro, dado que este é um computador portátil que, na pior das hipóteses, será acedido através de uma LAN fidedigna, via smb ou ssh. As palavras "efetivamente equivalentes ao acesso root" me assustam. Qualquer pensamento sobre isso é bem-vindo.