[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