
Estou tentando entender as permissões de arquivo em uma conta típica de hospedagem compartilhada do Linux. Eu sei como definir permissões rwx para as entidades OWNER GROUP e PUBLIC de um arquivo ou diretório. O que não está muito claro para mim é: normalmente, para onde seriam mapeadas as permissões de acesso? Eu estou supondo que:
DO UTILIZADORpermissões afetariam o que... uhm... não tenho certeza aqui
GRUPOpermissões afetariam o que um PHP ou outro script em execução no servidor poderia fazer
OUTRO(às vezes chamadas de PUBLIC ou WORLD?) afetariam o que o UA de um visitante do site pode fazer
Alguém pode corrigir, confirmar ou expandir meu entendimento sobre isso?
ESCLARECIMENTO:
Se eu quiser permitir que meu script PHP executado no servidor tenha permissão para gravar em um arquivo, essa permissão seria especificada em USUÁRIO, GRUPO ou OUTRO? Se eu quiser negar que o navegador de um visitante do site veja o conteúdo de um diretório, essa permissão seria especificada no USUÁRIO, GRUPO ou OUTRO do diretório?
Responder1
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 FTP
-rwxr-xr-x 2 FTPUSER yourgroup 72 2012-01-18 13:56 somescript.php
Agora .. porque o usuário WWWDAEMON WWWUSER não é você (FTPUSER), ele respeita OUTRAS permissões quando tenta usar read
seu script. (Existem sites de hospedagem que executam seus scripts como FTPUSER). Remover as outras permissões 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
Criar um diretório com permissões de gravação mundial permitirá que seu script escreva lá, mas a menos que você proteja esse diretório de alguma forma (como .htaccess ou coloque-o fora do seu diretório www), isso também pode significar que o NAVEGADOR 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 WWWDAEMON também respeita .htaccess ou similar para bloquear o acesso.
O conselho é criar uma palavra phpwritedir
e conceder-lhe direitos + rwx. Adicione .htaccess
o arquivo lá (se o seu serviço de hospedagem permitir)
deny from all
Com isso, seu script executado como WWWUSER ainda pode usar esse diretório, mas WWWDAEMON bloqueará qualquer acesso do BROWSER a ele.
Responder2
Você confundiu bastante.
ugo
ugo é user
, group
e other
- não owner
. Proprietário é o usuário, geralmente detentor da maioria dos direitos.
As permissões GROUP afetariam o que um PHP ou outro script em execução no servidor poderia fazer
As permissões de grupo não afetam o que pode ser feito (ler, escrever, executar), mas sim quem pode fazer isso. O mesmo para o usuário:
As permissões de USER (às vezes chamadas de PUBLIC?) afetariam o que o UA de um visitante do site pode fazer
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 abreviações ugo
ao usar chmod
, o que é mais fácil 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 grupo
- sample2: remova permissões de leitura do grupo e outros
- sample3: defina permissões de grupo para gravação
Cada arquivo pertence a um usuário e a 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 é tanto um usuário quanto um grupo. No entanto, mail e outras coisas são grupos que não são idênticos ao usuário.
atualização (após a atualização da pergunta):
Se eu quiser permitir que meu script PHP executado no servidor tenha permissão para gravar em um arquivo, essa permissão seria especificada em USUÁRIO, GRUPO ou OUTRO? Se eu quiser negar que o navegador de um visitante do site veja o conteúdo de um diretório, essa permissão seria especificada no USUÁRIO, GRUPO ou OUTRO do diretório?
Bem - não é permissão de um script fazer isso ou aquilo. É sempre a permissão do usuário que executa o script.
Para executar um script, o usuário deve ser capaz de 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, gravando em um diretório, for um servidor, normalmente não será iniciado por um usuário anônimo na web, mas por um usuário especial como 'www'.
Responder3
Como você fala sobre hospedagem compartilhada, deixe-me adicionar alguns detalhes divertidos sobre um hoster compartilhado com quem trabalho frequentemente. 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 existam 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 principal 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 colocam todos os usuários do host no mesmo grupo primário por questões de segurança, eu presumo.
Então agora posso ler meus arquivos, nenhum grupo pode lê-los (porque, bem, o grupo é nobody
), como o Apache os lê?
O Apache lê executando uma instância em sua própria conta de usuário. Por exemplo, com PHP, ele seria executado emModo CGIpara executar arquivos em sua conta.
Portanto, o primeiro octeto das permissões é 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 outros é equivalente à parte do proprietário.