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

O valor padrão para USERGROUPS_ENABin /etc/login.defsparece ser "yes", refletido no "Por padrão, um grupo também será criado para o novo usuário" que pode ser encontrado no useraddhomem, portanto, sempre que um novo usuário for criado, um O grupo é criado com o mesmo nome e apenas esse novo usuário. Existe algum uso para isso ou é apenas um espaço reservado?

Sinto que estamos perdendo uma parte do gerenciamento de direitos como usuário / grupo / outros ao fazer isso. Seria ruim ter um grupo "usuários" ou "regulares" ou o que você quiser chamar de grupo padrão para todos os usuários, 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 eles 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 fazendo isso e não tenho idéia do que poderia. O mesmo vale para os grupos padrão (tty, mem, etc.) aos quais nunca vi nenhum usuário pertencer.

Grupos por usuário

Eu também não vejo muita utilidade nos 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 seu grupo. Poucos sistemas que encontrei realmente o utilizam dessa maneira.

Quando USERGROUPS_ENABin /etc/login.defsestá definido como "não", useraddadiciona todos os usuários criados ao grupo definido /etc/default/useraddpelo GROUPcampo. Na maioria das distribuições, isso é definido como o GID, 100que geralmente corresponde ao usersgrupo. Isso permite que você tenha um gerenciamento mais genérico de usuários. Então, se você precisar de um controle mais preciso, poderá adicionar manualmente esses grupos e adicionar usuários a eles, o que faz sentido.

Grupos criados padrão

A maioria deles surgiu por razões históricas, mas muitos ainda têm usos válidos hoje:

• disk é o grupo que possui a maioria dos dispositivos de unidade de disco
• lp possui porta paralela (e às vezes é configurada para direitos de administrador em cups)
• O uucp geralmente possui portas seriais (incluindo portas seriais USB)
• cdrom é necessário para privilégios de montagem em uma unidade de CD
• Alguns sistemas usam wheel para direitos sudo; alguns não
• etc.

Outros grupos são usados ​​por scripts em segundo plano. Por exemplo, mangera arquivos temporários e outros quando executados; seu processo usa o grupo man para alguns desses arquivos e geralmente limpa depois de si próprio.

Porém, de acordo com a Especificação básica do Linux Standard , apenas 3 usuários root, bin e daemon são absolutamente obrigatórios . A lógica por trás dos outros grupos é:

O objetivo de especificar usuários e grupos opcionais é reduzir o potencial de conflitos de nomes entre aplicativos e distribuições.

Portanto, parece que é melhor manter esses grupos no lugar. É teoricamente 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 são renderizadas se você matar esse grupo, etc.). Não faz mal deixá-los lá, e geralmente é assumido que todos os sistemas Linux os terão.

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

Olá, sou jovem e você é horgix. Trabalhamos todos os dias e fazemos login no mesmo servidor Linux que os programadores. Um dia, não muito tempo atrás, nosso administrador do sistema decidiu facilitar a criação e a manutenção do usuário, então ele desativou a USERGROUPS_ENABopção e colocou todos os usuários existentes no novo usersgrupo.

Isso facilitou a criação de usuários, mas não a manutenção, pois todos os usuários podem acessar todos os outros arquivos de usuários. Em um ambiente corporativo, esse é um grande não-não devido a coisas como Sarbanes Oxley e Segregação de funções . Se eu criar o arquivo A, o bit do grupo será definido como o grupo de usuários, o que significa que todos os usuários podem ler pelo menos o arquivo a. e SoD porque departamentos separados não devem ser capazes de ler muito menos o documento de qualquer outra pessoa.

Com Usuário / Grupo ativado, se eu criar um documento como ecyoung, somente eu tenho direitos rwx. Como ninguém mais está no meu grupo, quando eles abrem meu documento, eles vêem uma página em branco com um aviso. Isso reforça 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. 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 usersgrupo com um GID de 100. Consulte a Pergunta 2 abaixo.

Hipotético :
você trabalha em TI e Louis trabalha em folha de pagamento. Louis mantém a planilha de impostos e folhas de pagamento em seu diretório pessoal, mas vocês dois estão no grupo de usuários; portanto, você abre o diretório pessoal porque está marcado com + r para os usuários e encontra sua planilha. Você encontra o seu salário listado, juntamente com o de Joe e Fred. Você acha que Joe e Fred gostariam de saber o salário deles?

Pergunta 2: IDs de grupo de 0 a 500

Os IDs de grupo e os IDs de usuário de 0 a 500 são reservados para contas do sistema e acesso ao dispositivo. Consulte a tabela 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 seu sistema de gerenciamento de pacotes. Se o fizer, 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 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 ALSA Sound System Daemon
• O serviço DBUS

Existem outros, portanto, se outros leitores quiserem adicionar ou remover da lista de serviços acima, faça-o.

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

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

Os grupos por usuário permitem que você tenha "privacidade no diretório inicial" e "fácil colaboração em pastas compartilhadas". Sem grupos por usuário, você pode ter um, mas não ambos. Os detalhes a seguir:

O Unix é um sistema multiusuário, seja um servidor de arquivos da empresa ou um PC 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 outras pessoas. Como alternativa, 027 ou 022, para que alguns ou todos possam ler, mas não gravar 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 causa de permissões estritas. Você pode alterar as permissões nesses arquivos, mas isso é "muito trabalho" e muitas vezes esquecido.

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

O grupo por usuário é a solução! Você usa umask 7, para que todos os arquivos criados sejam "rw para você e rw para o grupo". Os arquivos no diretório inicial são criados com o 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 específico.

Você ainda pode colaborar em pastas compartilhadas. Os arquivos na pasta compartilhada são "rw" para o grupo proprietário e o administrador do sistema configura a pasta compartilhada para que um grupo compartilhado (chamado de colaboradores) seja o proprietário do grupo dos arquivos. 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 SETGID ativado, qualquer coisa criada na pasta compartilhada terá o mesmo proprietário do grupo que a pasta compartilhada - ou seja, o grupo "colaboradores". E com umask 7 (ou alternativamente 2), todas as pessoas deste grupo terão acesso de leitura + gravação e poderão colaborar.

Originalmente, os processos Unix podiam pertencer a um grupo de cada vez (costumava haver um chgrp(1)comando, solicitando a senha do grupo armazenada no campo de senha vestigial em /etc/groups). Os sistemas Plus foram usados ​​por um grupo muito unido de usuários. Fazia sentido ter todos no usersgrupo e compartilhar coisas em todo o sistema por permissões de grupo. Nenhuma consciência real de segurança, pouca suspeita de cerca de uma dúzia de colegas usuários. Tudo era local, na mesma máquina. Nenhuma rede para compartilhar coisas, por exemplo, através de um blog ou algo assim.

Os sistemas Unix de hoje têm centenas de usuários, os requisitos de segurança são mais rigorosos e os usuários (e processos) podem pertencer a vários grupos. Dê a cada um dos usuários (mais sem noção) um grupo doméstico e permita que eles se afastem para compartilhar. Ou use ACLs.