authbind, privbind ou iptables REDIRECT (porta 80 a 8080)?

Question

Eu gostaria de rodar o Glassfish v3 como um usuário não privilegiado no Linux (Debian), mas disponibilizá-lo na porta 80. Eu estou fazendo isso com o iptables:

iptables -t nat -I PREROUTING -p tcp -d x.x.x.x --dport 80 -j REDIRECT --to-port 8080

Isso funciona, mas eu me pergunto:

1. Se isso tiver algum impacto significativo no desempenho em comparação à vinculação direta à porta 80
2. Se eu pudesse fazer uma configuração semelhante também funcionaria para HTTPS (ou se isso deve ser executado em 443)
3. Se houver uma maneira de evitar que outros usuários vinculem à porta 8080 (no caso do meu servidor travar) - talvez bloqueie essa porta permanentemente para outros usuários de alguma forma?

... ou se eu deveria usar authbind / privbind em vez disso? Problema: Eu não consegui fazer isso funcionar com authbind ou privbind até agora.

Para o authbind , editei a última linha do asadmin para:

exec authbind --deep "$JAVA" -Djava.net.preferIPv4Stack=true -jar ...

Para privbind :

exec privbind -u glassfish "$JAVA" -Djava.net.preferIPv4Stack=true -jar ...

(apenas) com essas configurações, posso executar com êxito create-domain --domainport 80 . Isso prova que authbind e privbind realmente funcionam (a versão authbind do script é chamada pelo usuário glassfish; a versão privbind é chamada pela raiz, é claro) . No entanto, em ambos os casos recebo a seguinte exceção, ao iniciar o domínio ( start-domain ):

[#|2010-03-20T13:25:21.925+0100|SEVERE|glassfishv3.0|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=11;_ThreadName=FelixStartLevel;|Shutting down v3 due to startup exception : Permission denied: 80=com.sun.enterprise.v3.services.impl.monitor.MonitorableSelectorHandler@1fc25e5|#]

Ainda não encontrei uma solução para isso (depois de pesquisar na Web, parece que isso não é tão fácil?) Mas talvez, a solução com iptables seja boa o suficiente - o que você acha?

Obrigado,

Chris

Nota:

Colocar um Apache na frente não é uma boa solução no meu caso - eu pretendo usar o Comet, e o Comet funciona melhor sem proxies.

    

Answer 1

Eu uso NAT o tempo todo em produção. Embora seja mais comumente usado para traduzir entre intranet e Internet, pode ser perfeitamente aceitável usá-lo dessa maneira também. Eu fiz semelhante para uma situação quase idêntica. Com isso dito, existem outras opções.

Os servidores de aplicativos e servidores da Web geralmente são executados juntos, portanto, faz sentido manter o Java em 8080 e 8443 internamente. Mais frequentemente, as pessoas provavelmente usariam o Apache como proxy para traduzir certas solicitações para Java e servir conteúdo estático da instância do Apache. Eu entendo que você acha esta solução inaceitável para você, mas deve ser dito.

Se isso não cobrir suas dúvidas, sinta-se à vontade para expor e eu irei continuar.

Editar 1

De nada. NAT não afetará a operação normal do https, ele funcionará bem.

Não consigo imaginar por que você estaria preocupado com a vinculação de outros usuários sem privilégios a 8080. Há algo exclusivo em sua situação?

    

Answer 2

Seu problema de privbind é provavelmente um resultado do HOME definido como root. Eu ou qualquer um que se apropriar de privbind de mim vai tentar corrigi-lo na próxima versão (agora que haverá uma próxima versão ...)

Veja se adicionar "HOME = ~ glassfish" no início da linha de comando (assumindo shell derivado de bourne) resolve o problema (se ainda for relevante: foram quatro anos desde que a pergunta foi feita, afinal de contas ... .)

Shachar