Lua scripts não podem setar uma metatable a um userdata, mas pode dar um getmetatable sobre um userdata? Se sim, ele podem alterar essa tabela? Se sim, posso ter r.contenttype = "text/html"?
Editar arquivo de copyright.
Verificar se existe alguma chamada em outras libs para obter o PATH do processo!
Impor um limite de consumo de memória no sandbox. Uma proposta de solução, sugerida pelo Roberto, é criar um userdata com um metamétodo __gc sem referência para ele. Assim, o GC sempre chamará ele no fim do processo. Quando ele rodar, testa se o state está consumindo além do limite e faz um long jump como o os.exit do sandbox (que passa os pcalls e xpcall internos) se estiver. Essa feature, valoriza o modelo adotado de sandbox, pois o outro modelo, proposto pelo Roberto, mistura a memória do sandbox com o Host. Todavia algumas lib alocam memória fora, o que prejudica essa solução.
Abrir a lib sandbox dentro de um sandbox é muito perigoso, permite consumir mais memória que o limitado pelo algoritmo proposto para limitar memória E permite stack overflow! Para limitar memória deveria ser posto o restante da memória ao sandbox dentro do sandbox! E limitar a profundidade de sandbox dentro de sandbox.
Impor um limite de uso de CPU. Sem uma idéia boa, apenas ver a interface de timeout do Apache. Uma proposta de solução que nasceu de um diálogo com Marco, é de utilizar um timer para controlar o tempo de execução total.
Por no sandbox algo como OpenBaseDir e ver o que o loadlib pode fazer, como o PHP. Aproveitar e ver o que pode ser copiado do PHP.
Permitir configurar as bibliotecas do sandbox. Isso permitirá colocar o acesso a lib do mysql, postgreSQL etc.
O método dofile do sandbox aceitar, além de um filename, um file handle. Isso será importante quando implementar WLua, onde o arquivo ser "parseado" on-the-fly do stream!
Fake stream agora suporta todos os modos de setvbuf. Antes era suportado apenas o _IONBF. Essa alteração tornou o fake stream mais flexível e mais parecido com um file handle. O motivo por de trás do impedimento anterior era por conta de uma "sutileza tão grande" da fopencookie que acredito ser um bug, mas descobri um workaround simples e muito educado para resolver. Ver a função bug_nullwriter no código para mais detalhes.
Fake stream: não é mais possível ter fake streams com operação de leitura e escrita ao mesmo tempo. Tive que remover essa funcionalidade porque é possível, colocando o stream em EOF estado e fazendo outras "gracinhas", provocar um segmentation fault de Lua! Isso ocorre porque o reader e writer deveriam representar um arquivo só, ou seja estár tudo sincronizado e não um lendo de um lugar e escrevendo em outro arquivo.
Fake stream: o evento de read passou a receber uma _sugestão_ para o tamanho do retorno. Esse tamanho não é obrigatório. Um importante uso é quando o fake stream está conectando um interface de stream que não é um filehandle. Isso ocorreu na comunicação com a API de conexão do Apache;
Generalizar a interface de fake stream. Foi adicionado um evento de close. Não foi possível, pois fopencookie não permite, adicionar um evento de flush, como sugeriu o Roberto. O comportamento de fread, ao invés de read foi implementado para ter um pequeno ganho de velocidade, não para remover bug, pois fopencookie espera o comportamento de read mesmo.
Por o código do sandbox no CVS.
Criar um .so para o sandbox.
Retirar pacote de sandbox de dentro de mod_lua e construir um pacote com o código.
Testar stack overflow e aninhamento de estrutura sintática com um script Lua. Resultado: Lua já tem proteções muito boas para isso internamente!
Implementar um fake_pcall e fake_xpcall para os.exit do box.
L:getenv também deve aceitar uma função do host, além de uma tabela. Resultado: depois de implementado isso se mostrou tão útil que passar uma tabela parece que foi feito depois!