Usuário único para compartilhamento versus vários usuários

Question

No meu laboratório, um grupo de pessoas trabalha cada uma em uma estação de trabalho e compartilha várias unidades pelo NFS. Eles executam software compartilhado residente em uma dessas unidades NFS e o executam nas unidades NFS onde os dados estão.

A configuração atual tem todos eles usando a mesma conta de usuário, vamos chamá-lo de one em todos os hosts. Os membros do laboratório fazem login como joe@myhost para ter uma área de trabalho com suas próprias personalizações, mas para qualquer trabalho real nos dados científicos, que pertençam a one , group users , eles devem se tornar one .

Observe que algumas personalizações por usuário do ambiente são obtidas com one accounts definidas como específicas do host e, portanto, têm seu diretório home local, por exemplo, one@myhost:/home/one (todas elas são UID 502 e GID 100 por motivos históricos). Portanto, a conta one de cada usuário pode ter variáveis de ambiente específicas definidas ao lado do PATH comum apontando para os programas compartilhados.

Atualmente, há um debate em andamento no laboratório em que estou sugerindo que é uma prática melhor no Unix ter contas separadas para usuários separados e replicar a funcionalidade atual de um único usuário usando grupos.

Eu listei as seguintes desvantagens da conta única

• dificuldade em gerenciar várias versões de software,
• auditoria / registro quase sem sentido,
• todos podem excluir arquivos e programas de outras pessoas,
• quando um membro deixa o laboratório, idealmente as senhas devem ser alteradas

Agora, esta rede está por trás de um firewall e são apenas dados científicos que seriam insignificantes para um intruso e não têm valor econômico. Além disso, tudo é secundário à produtividade em um laboratório científico de ritmo acelerado, incluindo segurança. Como os dados são frequentemente armazenados em backup, a capacidade de excluir dados ou programas também não é uma grande preocupação.

Como a abordagem da conta one é muito conveniente e foi estabelecida há muitos anos (2001?), estou tendo dificuldade em convencer alguém a acessar uma conta por usuário. Talvez eu esteja usando os argumentos errados, ou talvez o cenário que acabei de descrever seja tal que a abordagem one seja um meio-termo prático, e estou sendo inflexível em meu raciocínio.

Em ambos os casos, eu agradeceria se você pudesse me ajudar a descobrir se estou errado ou, se estou certo, sugerir como eu poderia discutir meu caso.

    

Answer 1

Bem, posso pensar em dois contra-pontos para a ideia de contas separadas.

Um, há uma grande falha com grupos unix clássicos versus uma árvore compartilhada comum de arquivos, e isso é que cada usuário e cada script que eles executam precisam ter umask que mantenha arquivos e diretórios agrupáveis por escrito; você precisa aplicar o bit group-sticky em todos os diretórios. Na prática, isso é difícil, porque muitos scripts especificam umask restritiva, e porque se você tiver rsync -a ou cp -a ou tar -x arquivos de um diretório que você possui na árvore comum, é fácil esquecer de adicionar pegajoso e mude o grupo para o compartilhado. O que você acaba com é uma sub-árvore de arquivos de propriedade de Joe e Joe está de férias ou fora para almoçar e alguém precisa modificar esses arquivos e você tem que ir encontrar o sysadmin para consertá-lo. IMHO o design de permissões Unix é simples e eficiente, mas não muito prático no mundo real.

Dois, se esta árvore comum de arquivos contiver binários, e todos tiverem adicionado esses caminhos ao seu $ PATH, então você não terá segurança alguma. Qualquer um dos seus usuários pode seqüestrar todo o grupo, então é melhor que todos realmente confiem um no outro. Além disso, você está usando o NFS, portanto, se os usuários podem assumir o controle de raiz em suas estações de trabalho, eles podem acessar os arquivos centrais como qualquer usuário que eles gostem.

Quanto à idéia de revogar contas de usuários, você consegue isso removendo-as da estação de trabalho local, que é onde a senha para one foi armazenada de qualquer maneira (certo?) porque com o NFS, o servidor de arquivos não tem idéia senha digitada, apenas que o kernel da sua estação de trabalho dizia "Oi, eu sou o UID 502, faça essas coisas em meu nome".

Portanto, antes de abordar o problema em sua organização, você deve pensar se realmente consegue realizar o que deseja.

Se você quiser que as versões do programa sejam menos caóticas, talvez os usuários peçam para você instalá-las, de propriedade de um administrador. A segurança é melhor quando um administrador está no controle de tudo em $ PATH.

Se você quiser contas separadas para poder ver quem está alterando os arquivos, talvez seja necessário escrever um daemon para monitorar a árvore compartilhada com o INotify (sugiro escrevê-lo em Perl) e forçar o g+rwx bits após cada evento 'open' e defina o UID após cada evento 'write'.

Espero que ajude ...