Conceder permissões de leitura ao usuário em todos os lugares (Linux)

Question

Eu tenho um usuário de "backup" no meu servidor que precisa ter permissões de leitura em todos os lugares. Fazer chown 444 -R / backup não parece ser a coisa certa a fazer, então o que devo fazer?

    

Answer 1

Você está misturando dois comandos:

• chown usado para alterar o proprietário de um arquivo. Exemplo: chown root:adm /etc/passwd

• chmod que é usado para alterar a permissão de um arquivo. Exemplo: chmod g+r myfile

Seja qual for o seu objetivo, você realmente não deseja que seu usuário de backup possua todos os arquivos e certamente não deseja ter todos os usuários em seu sistema o direito de ler todos os arquivos do seu sistema.

Qual é o seu objetivo?

    

Answer 2

No Linux, se você usar um sistema de arquivos compatível com ACL (ext3, ReiserFS, acho que o ZFS fará isso), você poderá definir o caminho de leitura e diretório para o usuário da operadora de backup.

Digamos que você queira fazer backup / home

1. Sua partição deve ser montada com a opção "acl" (você pode fazer isso com mount -o remount,acl /home )
2. Instalar ferramentas acl (setfacl e getfacl)
3. setfacl -R -m u:"Backup User":rx /home

Se você quiser garantir que novos arquivos e diretórios também tenham os direitos adequados, defina a ACL padrão:

4. setfacl -R -m d:u:"Backup User":rx /home

Você pode, obviamente, fazer isso com um grão mais refinado (por exemplo, se você não quiser fazer o backup de chaves gnupg ou ssh, - o que deve ser protegido por uma senha de qualquer maneira)

Realizar um backup como root não é sábio, IMHO. Primeiro, se você ficar inadvertidamente sem espaço em disco, poderá consumir até o último bloco disponível e tornar seu sistema instável. Segundo, se você não está completamente certo do script ou comando que você usa para backup, um usuário mal-intencionado pode fazer com que seu backup seja recursivo, ou fazer coisas desagradáveis como root.

Eu pessoalmente uso um mecanismo de rsync para sincronizar um servidor em uma réplica. Eu uso direitos de grupo simples na maioria dos pontos de sincronização, exceto para a casa onde eu uso as ACLs

    

Answer 3

O jeito certo de fazer isso não é alterando suas permissões de arquivo. Você deve usar sudo e / ou executáveis setuid.

    

Answer 4

chmod g+r myfile

g representa o grupo do arquivo (administradores).

r representa a permissão de leitura.

• representa o fato de que a permissão é adicionada.

Answer 5

chmod 0444 / arquivo. Para simplificar, use isto: link

    

Answer 6

A resposta simples é executar o backup como root. Na verdade, não fazendo coisas muito onerosas e / ou perigosas, essa é a única resposta até onde eu sei.

Se você fosse você não pode definir backup como o proprietário de everthing, nem você pode configurá-lo como o grupo para everthing, então a única outra maneira de dar acesso é dar acesso a todos. Simplificando, você executa backups como root ou bagunça o sistema.

É totalmente normal fazer o backup como root.

Bart.

    

Answer 7

Uma maneira pouco invasiva de fazer isso é adicionar seu usuário de backup a todos os grupos no sistema.

Esse usuário pertencente a cada grupo herdaria os direitos desses grupos, portanto, qualquer arquivo legível por grupo do qual você possa fazer backup. Isso incluiria o grupo raiz se você quiser fazer backup de arquivos de propriedade do root.

Isso não necessariamente permitirá que você faça backup de todos os arquivos, mas permitirá que você faça backup de todos os arquivos que os usuários não configurarem como particulares. Os arquivos que são X00 não serão armazenados em backup.

Uma das desvantagens dessa abordagem é que você deve acompanhar os novos grupos conforme eles são criados. Também requer, se você quiser fazer backup dos diretórios pessoais, que você defina pelo menos permissões de execução em / home (para grupo).

Como alguém mencionou, isso pode interromper o ssh com as chaves, dependendo da sua implementação.

    

Answer 8

- privs será curto para permissões (ou privilégios) -

quem se importa com o que "eles" dizem "deveria" / "não deveria" nem todos nós estamos administrando santuários de PCs no nível da NSA, e alguns de nós (como o cara no OP) podem se beneficiar de um pouco de leitura -toda política:

Um dos meus colegas tem uma caixa linux que tem tudo lido (além de pasta raiz e pasta lost + found) para que qualquer usuário (como eu possa encontrar coisas legais em sua pasta / home / notme ou em / etc / folder )

sudo chmod -R +r /
sudo chmod -R 700 /root
sudo chmod -R 700 /lost+found

OBSERVAÇÃO: a pasta / root provavelmente pertence a root: root (usuário raiz e grupo raiz), mas nós dissemos root group no privs ... Bem, tudo bem, porque o usuário root ainda tem priv, e isso é o que mais importa se certo? Basicamente, se o seu usuário root, e você tentar entrar em uma pasta / arquivo que diz usuário root você tem privs completos, mas o grupo raiz você não tem privs ... quem ganha? Bem root privs usuário dizer que você pode entrar de modo que é o que importa (o grupo raiz privs nem sequer se olhou) .. Também desde o seu usuário root você pode mudar tudo isso