Proprietários / permissões padrão de arquivos no diretório inicial do usuário


14

Frequentemente, vejo usuários que tentam corrigir um problema e em algum lugar lêem ou apenas tentam recursivamente chowno diretório pessoal e, às vezes, até redefinem as permissões recursivamente para algo parecido rwxr-xr-xou semelhante.

Imagine um massacre de proprietário / permissão - existem arquivos / diretórios críticos que precisam de permissões especiais ou pertencem à raiz para que o sistema funcione?


1
De que arquivos você está falando? Por que os arquivos críticos pertencentes ao root estão em uma página inicial do usuário?
Mikewhatever 11/09/2015

1
@mikewhatever Conheço pelo menos três diretórios que precisam ser detida pela raiz: ~/.gvfs/, ~/.cache/gvfs-burn/e ~/.cache/dconf. Provavelmente há mais.
Byte Commander

1
drwx------ 2 romano romano 4096 dic 2 2008 .gvfse nunca teve nenhum problema .... (veja a data). Tambémdrwx------ 2 romano romano 4096 abr 28 14:57 .cache/dconf
Rmano

3
Não há arquivos "críticos" no diretório inicial do usuário, se houver, é o resultado de uma programação muito ruim, pois o usuário pode removê-los de propósito / por engano em um instante. A menos que seja um erro, os arquivos "críticos" são armazenados em outro local.
kos

FWIW, posso confirmar que ~ / .gvfs e ~ / .cache / dconf no meu sistema são de propriedade do root. Eu executei "sudo ls -Al" nos dois diretórios e ambos estão vazios. Embora eu tenha alterado as permissões de grupo e outras para documentos, nunca executei o chown. Portanto, a propriedade raiz desses dois diretórios pode ser normal, pelo menos para o Ubuntu 15.04. Além disso, eu não tenho um diretório ~ / .cache / gvfs-burn ou os diretórios ipc-admin mencionados pelo Byte Commander que pertencem à raiz. Mas, o arquivo numérico com nome alfa em ~ / .dbus / session-bus é de propriedade de Mim, não de raiz.
user173876

Respostas:


17

Nenhum arquivo ~deve pertencer à raiz.

Se um software exigir que um arquivo em seu diretório pessoal seja de propriedade de outro usuário, é um bug e deve ser relatado como tal.

Fora isso, um caso comum envolve dois softwares relacionados à segurança que exigem permissões restritas em determinados arquivos, a saber:

  1. SSH
  2. GPG

SSH

Veja a man sshseção FILES:

 ~/.ssh/config
     This is the per-user configuration file.  The file format and
     configuration options are described in ssh_config(5).  Because of
     the potential for abuse, this file must have strict permissions:
     read/write for the user, and not writable by others.  It may be
     group-writable provided that the group in question contains only
     the user.

 ~/.ssh/identity
 ~/.ssh/id_dsa
 ~/.ssh/id_ecdsa
 ~/.ssh/id_ed25519
 ~/.ssh/id_rsa
     Contains the private key for authentication.  These files contain
     sensitive data and should be readable by the user but not acces‐
     sible by others (read/write/execute).  ssh will simply ignore a
     private key file if it is accessible by others.  It is possible
     to specify a passphrase when generating the key which will be
     used to encrypt the sensitive part of this file using 3DES.

Outros arquivos como authorized_keys, known_hostsetc. devem ser graváveis ​​apenas pelo usuário, mas podem ser legíveis pelo mundo.

GnuPG

~/.gnupg(e conteúdo) deve ser acessível somente por você. Com outras permissões, o GPG se queixará de permissões não seguras.


Então ~/.gvfs/, ~/.cache/gvfs-burn/e quanto ~/.cache/dconf? Eles são de propriedade da raiz e acho que deveriam.
Byte Commander

2
@ByteCommander não. Use sudocom programas GUI, não é?
muru 11/09/15

Não que eu pudesse me lembrar ... Estou criando um novo usuário e verificando lá. Um momento por favor.
Byte Commander

@ByteCommander dá uma olhada: bugzilla.gnome.org/show_bug.cgi?id=534284
muru

1
@ByteCommander, se essa era a intenção, então sudo -iou sudo -Hprovavelmente deveria ser usado.
muru 11/09/15

11

Em geral, os arquivos e diretórios em sua casa devem pertencer a você.
Eu tenho alguns arquivos estranhos de propriedade da raiz que provavelmente são o resultado da execução do sudocomando; de fato, existem programas que escrevem coisas $HOME(os quais programas bem comportados que exigem privilégios de superusuário não deveriam funcionar - o efeito é a propriedade raiz dos arquivos que deveriam pertencer ao usuário).
Normalmente, excluí-los ou possuí-los novamente (dependendo do arquivo) não cria problemas e geralmente resolve alguns, como o .Xauthorityarquivo infame - e, às vezes, após a execução sudo dconf-editor, você tem coisas nas configurações que não podem mais ser modificadas.

Sobre modos especiais:

  • os scripts devem ser executáveis, é claro, pelo menos para o proprietário;
  • também devem ser diretórios (onde xsignifica direito de atravessar);
  • .sshdeve ser drwx------(0700) e as chaves privadas -rw-------(0600)
  • se você tiver um Publicdiretório para compartilhar, provavelmente deve ser drwxr-xr-x(permissão de leitura para qualquer pessoa) ou drwxrwxrwt(com permissão de gravação e bit pegajoso, para ativar a gravação).

... Não consigo pensar em mais nada que precise de tratamento especial.


Então ~/.gvfs/, ~/.cache/gvfs-burn/e quanto ~/.cache/dconf? Eles são de propriedade da raiz e acho que deveriam.
Byte Commander

@ ByteCommander --- todas as coisas que pertencem a mim no meu sistema e nada funciona mal. Por que você acha que eles devem pertencer à raiz? In dconfé a sua configuração, e o comando / daemon privilegiado que faz a montagem das partições deve mudar de propriedade para você --- caso contrário, é um bug. Eu comentei isso em sua pergunta.
Rmano 11/09

Eu encontrei outros dois arquivos de propriedade de raiz que eu não tenho certeza se é certo ou errado: ~/.dbus/session-bus/7ae519bec942595a6925fb2d5448031b-1e /home/ipc-admin/.aptitude/config, muita coisa sob /home/ipc-admin/.cache/pip/wheels/, /home/ipc-admin/.local/share/session_migration-(null)e /home/ipc-admin/.local/share/applications/mimeapps.list. Você pode imaginar por que essas propriedades são de raiz no meu sistema?
Byte Commander
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.