[Cascavel-pm] Restringir_acesso_de_leitura_à_pasta_do_usuário

Luis Campos de Carvalho lechamps em terra.com.br
Sexta Agosto 1 09:32:27 CDT 2003


Raul Dias wrote:
> Oi,

   Olá, Raul.
   Benvindo! =-]

> Esta ocorrendo um erro conceitual do que é realmente o mod_perl.
> 
> mod_perl não é uma como o php que permite incluir páginas com código
> junto do html.  Bem, ele permite fazer isso, mas isso é apenas uma
> conseqüência.
> 

   Correto.

> mod_perl é uma extensão do apache em que se coloca o interpretador perl
> inteiro dentro do apache em que ele exporta _toda_ a API do apache em
> Perl.  Programas/scripts rodando com mod_perl não são um processo
> separado, mas fazem parte do mesmo processo do apache (pelo menos do
> Child em que foi chamado).  Btw, por isso chroot não faz sentido nesse
> caso a não ser que se tenha vários apaches em portas diferentes.
> 

   Foi o que eu quis dizer. Cada usuário terá acesso a uma instancia 
separada do Apache + Mod_Perl, que vai rodar "enjaulado" via chroot().

> Como conseqüência, qualquer script rodando sob mod_perl será o usuário
> do apache (www, web, nobody, ...).  Por isso não haveria como restringir
> sem patchs profundos no perl, mod_perl e apache.
> 

   Não necessariamente. Podemos disparar o apache como root e solicitar 
mudança para um UID/GID diferente para cada usuario, utilizando 
configurações diferenciadas para o Apache. Claro, mais trabalho...

> Mas nem tudo esta perdido.
> Existe um patch/módulo em algum lugar que permite que o apache rode como
> usuário diferente para cada domínio virtual.  Nesse caso com uma
> configuração bem apertada, é possível fazer o que você quer.
> Algumas considerações:
> - o patch/módulo é para apache 2 e é experimental (pré-alpha).
> - o mod_perl para apache 2 é considerado experimental e instável.
> - Você terá a quantidade de recursos que o apache gasta hoje vezes o   
>   número de usuários em que ele rodará (serão processos separados)
>   apenas para ele ficar inativo.

   Eu particularmente não me arriscaria com isso em procução... mas é 
uma escolha bem pessoal, acho que o Guilherme pode decidir sobre isso 
melhor que qualquer um de nós...

> 
> Se esse tipo de restrição é para evitar que um usuário acesse algo que
> não deveria via mod_perl, esse é o menor dos seus problemas. mod_perl é
> poderoso de mais (IMO) para permitir que pessoas não-confiáveis ou sem a
> capacidade necessária acessem.
> 

   Eu estou de acordo: mod_perl não pode ser utilizado desta forma sem 
um *bom* estudo antes. Normalmente, alocamos uma máquina exclusivamente 
para isso, e definimos uma API sólida para a comunicação... mas isso é 
outra história.

   []'z!
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
   Luis Campos de Carvalho is Computer Scientist,
   PerlMonk [SiteDocClan], Cascavel-pm Moderator,
   Unix Sys Admin && Certified Oracle DBA
   http://br.geocities.com/monsieur_champs/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=




Mais detalhes sobre a lista de discussão Cascavel-pm