Sem sombra de dúvidas, tomei a liberdade de citar trechos de alguns artigos publicados aqui para exemplificar o dito na página anterior, sem citar link de acesso e muito menos informar o autor do artigo, para não causar exposição desnecessária e nem gerar conflitos éticos.

Usando o sistema de busca do site procurei por artigos que contivessem a string "chmod 777". A maioria retornou artigos de instalação e configuração de serviços, sobretudo Apache e Squid. O exemplo que pego aqui é de um artigo que ensina como baixar, instalar, configurar e rodar o Squid em uma tradicional distro Linux. Em um trecho do artigo, o autor informa o seguinte:

"Criar o diretório de cache.

# chmod 777 /usr/local/squid/cache

Dar permissão de gravação no diretório de cache.

# chmod 777 /usr/local/squid/logs

Dar permissão de gravação no diretório de logs.

# chmod 777 /usr/local/squid/etc/errors

Dar permissão de gravação no diretório de erros, importante para verificar quando houver algum problema com o serviço.

# chown nobody.nogroup /usr/local/squid/cache

Comando para mudar o dono do diretório de cache.

# /usr/local/squid/bin/squid -z

Cria o swap Directory.

# /usr/local/squid/bin/squid -D "

Para quê dar permissão para todo mundo nos diretórios e arquivos do proxy Squid? Uma das vantagens de se ter Squid é poder analisar os logs e tomar medidas consonantes com o que estiver ocorrendo com o serviço. Se tivermos um usuário mais "espertinho" e quiser deletar do Squid o rastro de algo que ele acessou, sem problemas! As permissões dos arquivos e diretórios permitem isso! Sem contar na possibilidade de se usar falhas de segurança como esta para obter vantagens indevidas a outros recursos do sistema. Perigoso! O mais adequado neste caso é mudar o DONO dos diretórios que o Squid precisa para funcionar. Cria um usuário apenas para os processos do Squid, dá permissão nos diretórios somente para este usuário e configura o mesmo para acessar um shell restritivo que não permita que ninguém logue com ele para fins ilícitos. Reduz bastante a chance de termos algum bisbilhoteiro fuçando os nossos serviços.

Indo para softwares que rodam em ambiente web, fiz uma busca para a string "grant all privileges". Retornou alguns artigos. Uso um trecho de um deles a seguir:

"O próximo passo é dar privilégios a um usuário que não seja o root para ter acesso ao banco que acabamos de criar. Faremos isso com os comandos:

# mysql -u root -p

Este comando irá abrir o console do MySQL. Dentro deste console, iremos digitar:

mysql> GRANT ALL PRIVILEGES ON drupal.* TO usuário@localhost IDENTIFIED BY 'senha';"

Se uma aplicação web precisa ter acesso full e irrestrito a um banco de dados, temos um sério problema! Trabalho com web há um bom tempo e hoje cuido de um sistema de gestão de qualidade de service desk em uma multinacional americana. E também já cuidei de diversos sistemas de gestão de incidentes baseados em web e banco de dados. Particularmente, mesmo em ambiente crítico como citei, nunca presenciei ou tomei conhecimento de uma aplicação web ter necessidade de acesso irrestrito a todo o banco de dados! Se algum atacante descobrir um jeito de injetar comandos SQL pela sua aplicação (se você não tiver o mod_security, claro) você vai facilitar muuuuuuuuuuuuuuuuuuuito o trabalho dele =/