Razões por trás dos grupos e usuários padrão no Linux

14

Veja os usuários padrão & gerenciamento de grupos em algumas distribuições usuais do Linux (ArchLinux e Debian, respectivamente), eu estou querendo saber duas coisas sobre isso e sobre as conseqüências de modificar a configuração e configuração padrão.

O valor padrão para USERGROUPS_ENAB em /etc/login.defs parece ser "sim", o que é refletido pelo "Por padrão, um grupo também será criado para o novo usuário" que pode pode ser encontrado em useradd man, então cada vez que um novo usuário é criado, um grupo é criado com o mesmo nome e somente esse novo usuário entra. Existe algum uso para isso ou isso é apenas um espaço reservado?

Estou sentindo que estamos perdendo uma parte do gerenciamento de direitos como usuário / grupo / outros fazendo isso. Seria ruim ter um grupo de "usuários" ou "regulares" ou o que você quiser chamá-lo que é o grupo padrão para cada usuário, em vez de ter o seu próprio?

Segunda parte da minha pergunta, que ainda é baseada no que eu vi no Arch e no Debian: existem muitos usuários criados por padrão (FTP, HTTP, etc.). Existe alguma utilidade para eles ou existem apenas por razões históricas?

Estou pensando em removê-los, mas não quero quebrar nada que possa usá-lo, mas nunca vi nada assim, e não tenho ideia do que poderia. O mesmo vale para os grupos padrão (tty, mem, etc.) aos quais nunca vi nenhum usuário.

    
por Horgix 19.09.2014 / 21:18

5 respostas

13

Grupos por usuário

Eu também não vejo muita utilidade em grupos por usuário. O principal caso de uso é que, se um usuário quiser permitir que "amigos" acessem seus arquivos, ele poderá adicionar o usuário amigo ao grupo. Poucos sistemas que encontrei realmente usam dessa maneira.

Quando USERGROUPS_ENAB em /etc/login.defs está definido como "não", useradd adiciona todos os usuários criados ao grupo definido em /etc/default/useradd pelo campo GROUP . Na maioria das distribuições, isso é definido como o GID 100 , que geralmente corresponde ao grupo users . Isso permite que você tenha um gerenciamento mais genérico de usuários. Então, se você precisar de um controle melhor, você pode adicionar manualmente esses grupos e adicionar usuários a eles que façam sentido.

Grupos criados por padrão

A maioria deles surgiu por motivos históricos, mas muitos ainda têm usos válidos hoje em dia:

  • disco é o grupo que possui a maioria dos dispositivos de unidade de disco
  • lp possui porta paralela (e às vezes é configurado para direitos de administrador em xícaras)
  • o uucp geralmente possui portas seriais (incluindo portas seriais USB)
  • o cdrom é necessário para montar privilégios em uma unidade de cd
  • Alguns sistemas usam roda para direitos de sudo; alguns não
  • etc.

Outros grupos são usados por scripts de segundo plano. Por exemplo, man gera arquivos temporários e quando é executado; seu processo usa o grupo man para alguns desses arquivos e geralmente limpa depois de si.

De acordo com a especificação básica do Linux Standard Base embora, apenas 3 usuários que são root, bin e daemon são absolutamente obrigatórios . O raciocínio por trás dos outros grupos é:

The purpose of specifying optional users and groups is to reduce the potential for name conflicts between applications and distributions.

Portanto, parece que é melhor manter esses grupos no lugar. É teórico possível removê-los sem quebras, embora para alguns, coisas "misteriosas" possam começar a não funcionar corretamente (por exemplo, algumas páginas de manual não renderizando se você matar esse grupo, etc). Não faz nenhum mal deixá-los lá, e geralmente é assumido que todos os sistemas Linux os terão.

    
por 19.09.2014 / 21:41
4

Pergunta 1: Raciocínio para o mesmo usuário e grupo

Olá, eu sou ecyoung e você é horgix. Nós vamos trabalhar todos os dias e fazemos o login no mesmo servidor Linux que os programadores. Um dia, não muito tempo atrás, nosso administrador do sistema decidiu tornar a criação e a manutenção do usuário mais fácil para si mesmo, então ele desativou a opção USERGROUPS_ENAB e colocou todos os usuários existentes no novo grupo users .

Isso facilitou a criação do usuário, mas não a manutenção, porque todos os usuários podem acessar todos os outros arquivos de usuários. Em um ambiente corporativo, este é um grande não, não devido a coisas como Sarbanes Oxley e Segregação de Deveres . Se eu criar o arquivo A, o bit de grupo é definido para o grupo de usuários, o que significa que todos os usuários podem pelo menos ler o arquivo A. Se o administrador do sistema é preguiçoso, em alguns casos todos os usuários podem RW arquivo A. Isso derruba Sarbanes Oxley e SoD porque os departamentos separados não devem poder ler muito menos escrever qualquer documento de outras pessoas.

Com o usuário / grupo habilitado se eu criar um documento como ecyoung, então eu só tenho direitos rwx para ele. Como ninguém mais está no meu grupo, quando abrem meu documento, vêem uma página em branco com um aviso. Isso impõe Sarbanes-Oxley e SoD. Se eu convidar outros usuários, esses usuários terão acesso rw e, ao fazer isso, sei que o que eles vêem não voltará para me morder ou a eles. Como outros já disseram, se em casa, essa separação pode não ser importante para você. Se você determinar isso, poderá desativar a opção com segurança e todos os usuários serão adicionados a um grupo users com um GID de 100. Consulte a pergunta 2 abaixo.

Hipotética :
Você trabalha em TI e Louis trabalha na folha de pagamento. Louis mantém o Imposto e folha de pagamento em seu diretório pessoal, mas você está no grupo de usuários, portanto, abre o diretório pessoal dela porque está marcado + r para os usuários e encontra a planilha. Você encontra seu valor de salário listado, junto com Joe e Fred. Você acha que Joe e Fred gostariam que você soubesse o salário deles?

Pergunta 2: ID do grupo de 0 a 500

As IDs do grupo e vice-versa. As IDs do usuário de 0 a 500 são reservadas para contas do sistema e acesso ao dispositivo. Consulte a tabela de grupos de sistemas pré-configurados para obter a lista de contas padrão. Por favor, não remova essas contas manualmente. Por exemplo, se você deseja remover o usuário ftp, remova o daemon ftp com o sistema de gerenciamento de pacotes. Isso também removerá a conta do sistema. Os serviços do sistema incluem, mas não estão limitados a:

  • O serviço de impressão do CUPS
  • O daemon do servidor MySQL
  • O daemon do servidor FTP
  • O servidor da web Apace
  • O soquete do servidor X para conexões remotas
  • O daemon do sistema de som ALSA
  • O serviço DBUS

Existem outros, por isso, se outros leitores quiserem adicionar ou remover da Lista de serviços acima, faça isso.

    
por 19.09.2014 / 22:34
3

Se todos nós compartilharmos um grupo padrão, como nos velhos tempos, precisamos definir nossa umask como 077 para bloquear o grupo. Se o padrão é eu, então eu posso definir o umask para 027, agora se eu definir um diretório de arquivo para um grupo compartilhado, este grupo pode ler. Eu não tenho que mexer com os modos também.

Este é apenas um exemplo, mas em geral é uma maneira de desabilitar grupos, até que você precise deles, de uma maneira que os torne mais fáceis de ativar e gerenciar.

    
por 10.10.2015 / 20:49
1

Grupos por usuário permitem que você tenha "privacidade em seu diretório pessoal" e "colaboração fácil em pastas compartilhadas". Sem grupos por usuário, você pode ter, mas não ambos. Detalhes seguem:

O Unix é um sistema multiusuário, seja um servidor de arquivos da empresa ou um computador com 2 usuários. A "privacidade no seu diretório pessoal" pode ser realizada de várias maneiras:

Defina "umask 077" para que os arquivos sejam criados com rw para você e sem permissões para outros. Alternativamente, 027 ou 022, então alguns ou todos podem ler, mas não escrever seus arquivos. A desvantagem óbvia é que você não pode colaborar em uma pasta compartilhada porque os outros não podem trabalhar nos arquivos criados por você devido a permissões restritas. Você pode alterar permissões em tais arquivos, mas isso é "muito trabalho" e muitas vezes esquecido.

Para colaborar, você quer algo como "umask 7" para que você e o grupo proprietário possam ler & gravar arquivos criados por você. Isso é ótimo para pastas compartilhadas e grupos que consistem em todas as pessoas que precisam de acesso compartilhado. Mas você perde a privacidade em sua pasta pessoal!

O grupo por usuário é a solução! Você usa umask 7, então todos os arquivos que você fizer receberão "rw para você e rw para o grupo". Os arquivos em seu diretório pessoal são criados com seu grupo pessoal como "grupo proprietário", para que ninguém mais possa acessar esses arquivos, apesar da permissão "group rw". Porque ninguém além de você está nesse grupo em particular.

Você ainda pode colaborar em pastas compartilhadas. Os arquivos na pasta compartilhada obtêm "rw" para o grupo proprietário e o sysadmin configura a pasta compartilhada para que um grupo compartilhado (chamado de colaboradores) seja o proprietário do grupo para os arquivos lá. Isso é feito criando esse grupo de colaboradores, com todos os usuários colaboradores como membros. Em seguida, o administrador define a propriedade do grupo da pasta compartilhada como "colaboradores" e define a permissão SETGID para a pasta compartilhada. Com o SETGID ativado, qualquer coisa criada na pasta compartilhada receberá o mesmo proprietário do grupo da pasta compartilhada, ou seja, o grupo "colaboradores". E com umask 7 (ou alternativamente 2), as pessoas deste grupo terão acesso de leitura + escrita e poderão colaborar. Eles não precisarão alterar as permissões do padrão para os arquivos compartilhados - e eles ainda terão privacidade em suas pastas iniciais graças aos grupos por usuário usados lá.

    
por 19.01.2017 / 11:16
0

Originalmente, os processos Unix podiam pertencer a um grupo de cada vez (costumava haver um comando chgrp(1) , solicitando a senha do grupo armazenada no campo de senha residual em /etc/groups ). Além disso, os sistemas foram usados por um grupo estreito de usuários. Faz sentido ter todo mundo no grupo users e compartilhar todo o sistema por permissões de grupo. Nenhuma consciência de segurança real, pouca desconfiança de cerca de uma dúzia de usuários. Tudo era local, na mesma máquina. Nenhuma rede para compartilhar coisas, por exemplo através de um blog ou mais.

Os sistemas Unix atuais possuem centenas de usuários, os requisitos de segurança são mais restritos e os usuários (e processos) podem pertencer a vários grupos. Dê a cada um dos usuários (mais ignorantes) um grupo doméstico e permita que ele se desvie dele para compartilhamento. Ou use ACLs.

    
por 11.10.2015 / 01:09