Permissões em um host da Web compartilhado típico do Linux

Question

Estou tentando entender as permissões de arquivo em uma conta típica de hospedagem compartilhada do Linux. Eu sei como definir permissões de rwx para as entidades de OWNER GROUP e PUBLIC de um arquivo ou diretório. O que não é muito claro para mim é, normalmente para onde as permissões de acesso são mapeadas? Eu estou supondo que:

As permissões

USER afetariam o que ... uhm ... não tem certeza aqui, as permissões GROUP afetariam o que um script PHP ou outro script em execução no servidor poderia do
OUTRAS (às vezes chamadas de PÚBLICO ou MUNDIAL?) as permissões afetariam o que um usuário de um visitante do site pode fazer

Alguém pode corrigir, confirmar ou ampliar meu entendimento sobre isso?

ESCLARECIMENTO:

Se eu quiser permitir que meu script PHP que executa no servidor a permissão para gravar em um arquivo, essa permissão seria especificada em USER, GROUP ou OTHER? Se eu quiser negar o navegador de um visitante do site para ver o conteúdo de um diretório, essa permissão seria especificada no USER, GROUP ou OTHER da pasta?

    

Answer 1

Vamos especificar algumas palavras-chave.

FTPUSER   = you with your ftp client
WWWDAEMON = program (servers) that's responsible for processing your web pages and scripts 
WWWUSER   = user as which the WWWDAEMON processes your pages
BROWSER   = Someone looking at your website with a browser
FILES     = files that reside in your www/ftp site
yourgroup = group that your FTPUSER belongs to and WWWUSER does not

Você acessa seus arquivos como FTPUSER com um programa de ftp

-rwxr-xr-x  2 FTPUSER yourgroup   72 2012-01-18 13:56 somescript.php

Agora ... porque WWWDAEMON usuário WWWUSER não é você (FTPUSER) ele respeita OUTRAS permissões quando tenta read seu script. (Há sites de hospedagem que executam seus scripts como FTPUSER). A remoção da outra permissão de leitura e execução bloqueará o uso de somescript.php

# this scipt is unusable trough a browser
-rwxr-x---  2 FTPUSER yourgroup   72 2012-01-18 13:56 somescript.php

A criação de um diretório com permissões graváveis permitirá que o seu script seja escrito, mas a menos que você proteja esse diretório de alguma forma (como com o .htaccess ou coloque-o fora do diretório www) também pode significar que o BROWSER pode acessar esses arquivos diretamente porque:

BROWSER contacts WWWDAEMON which runs as WWWUSER so 
BROWSER can see everything processed by WWWDAEMON that the WWWUSER can. 

Processado também significa que o WWWDAEMON também respeita o .htaccess ou similar ao bloqueio de acesso.

O conselho é criar digamos phpwritedir e dar a ele direitos + rwx. Adicione o arquivo .htaccess lá (se o seu serviço de hospedagem permitir)

deny from all

Com este script rodando como WWWUSER ainda pode usar este diretório, mas o WWWDAEMON bloqueará qualquer acesso do BROWSER a ele.

    

Answer 2

Você entendeu muito bem.

ugo ugo é user , group e other - não owner . Proprietário é o usuário, geralmente detendo mais direitos.

GROUP permissions would affect what a PHP or other script running on the server could do

As permissões do grupo não afetam o que pode ser feito (ler, escrever, executar), mas quem pode fazê-lo. O mesmo para o usuário:

USER (sometimes called PUBLIC?) permissions would affect what a UA of a web site visitor can do

O usuário é o proprietário, mas o é usado para other , que é o que você chama de público. E novamente - é quem pode fazer, não o que pode ser feito.

Você pode usar as abreviaturas ugo ao usar chmod , o que é mais fácil do que os códigos numéricos:

  chmod ug+w sample1
  chmod go-r sample2 
  chmod g=w  sample3 

• sample1: adicione permissões de gravação ao usuário e ao grupo
• sample2: remova as permissões de leitura do grupo e de outras
• sample3: definir permissões de grupo para gravar

Cada arquivo é de propriedade de um usuário e um grupo. Veja-os com ls -l . Exemplo:

ls -l /var
insgesamt 12
drwxr-xr-x  2 root root   592 2012-01-12 08:02 backups
drwxr-xr-x 28 root root   776 2011-08-18 05:12 cache
drwxrwxrwt  2 root root    48 2010-06-22 01:46 crash
drwxr-xr-x  2 root root  3704 2010-06-05 22:01 games
drwxr-xr-x 84 root root  2296 2011-10-16 13:25 lib
drwxrwsr-x  2 root staff   48 2007-10-08 12:47 local
drwxrwxrwt  3 root root    80 2012-01-19 08:03 lock
drwxr-xr-x 22 root root  5992 2012-01-19 08:01 log
drwxrwsrwt  2 root mail    72 2012-01-18 07:56 mail

Uma parte da listagem de / var. A maioria dos diretórios (d ...) pertencem a root.root, que é também um usuário, como um grupo. No entanto, email e outras coisas são grupos, que não são idênticos ao usuário.

atualizar (após a atualização da pergunta):

If I want to allow my PHP script that run on the server the permission to write to a file, would that permission be specified in USER, GROUP or OTHER? If I want to deny a website visitor's browser to see the contents of a directory, would that permission be specified in the dir's USER, GROUP or OTHER?

Bem - não é a permissão de um script para fazer isso ou aquilo. É sempre a permissão do usuário que executa o script.

Para executar um script, o usuário deve poder lê-lo, ou seja, ele é lido do disco para colocá-lo na memória, para executá-lo. Você não pode executá-lo, sem lê-lo.

Para gravar em um arquivo, o usuário precisa ter permissão para gravar em um diretório - não no script ou programa.

Se o programa, escrevendo para um diretório, é um servidor, normalmente não é iniciado a partir de um usuário anônimo na web, mas de um usuário especial como 'www'.

    

Answer 3

Como você fala sobre hospedagem compartilhada, deixe-me adicionar alguns detalhes divertidos sobre um hoster compartilhado com o qual eu frequentemente trabalho. Pela minha experiência, uma configuração como essa não é incomum em ambientes de hospedagem compartilhada.

Em ambientes de hospedagem compartilhada, não é incomum que haja vários usuários compartilhando o mesmo host com você. Naturalmente, todos eles têm contas de usuário.

Minha conta de usuário pode ser 123456-user1 . Agora, o que é feito é que meu grupo primário está definido como nobody ou nogroup , para que todos os novos arquivos e pastas que eu gero pertençam a 123456-user1:nobody .

Eles não apenas lançam todos os usuários no host no mesmo grupo principal por questões de segurança que eu diria.

Então agora eu posso ler meus arquivos, nenhum grupo pode lê-lo (porque, bem, o grupo é nobody ), como o Apache o lê?
O Apache o lê executando uma instância sob sua própria conta de usuário. Por exemplo, com o PHP, ele seria executado no Modo CGI para executar arquivos na sua conta. / p>

O primeiro octeto das permissões é o que é relevante para todo o sistema. Ele define o que você e os visitantes do site (por assim dizer) podem fazer com o arquivo. O grupo pode ser ignorado. E o último octeto para os outros é um pouco equivalente à parte do dono.