Em 22 de janeiro de 2016 09:13, Dickson S. Guedes <[email protected]> escreveu:
> Em 21 de janeiro de 2016 22:24, Douglas Fabiano Specht > <[email protected]> escreveu: > > boa noite pessoal, > > como vamos ter algumas funções no banco de dados, como podemos > restringir a > > visualização dos fontes das funções? > > encontrei algumas pagas mas queria algo open, ou nativo > > A dica do Osvaldo é muito bem vinda, como não houveram outras > respostas e talvez você não queira fazer em C, podem haver outras > alternativas então vou fazer um adendo: > > Primeiramente vamos partir das premissas que, seja qual for a > linguagem ou o método que você aplicar, não estarás seguro totalmente > e que se alguém está "furtando" seu código ou ideias dele há ai um > outro problema, pois, se alguém realmente quiser pegar o conteúdo da > sua função ele vai dar um jeito de fazê-lo. Restringir o acesso em > termos de permissões também é complicado porque o usuário tem acesso > ao conteúdo da função via catálogo, claro. Com um pouco de coragem e > conhecimento seria possível burlar mas não para ambiente critico ou de > produção, apenas para caráter de estudo e conhecimento e ainda assim > com resultados imprevisíveis, podendo, inclusive, quebrar o > funcionamento de aplicações de monitoramento ou de administração. > > Mas nada impede de você dificultar este acesso para que pelo menos os > usuários mais comuns ou mal intencionados tenham alguns níveis de > dificuldade. > > Vamos lá, você não especificou em qual linguagem suas funções estão > escritas então eu vou divagar aqui sobre três possibilidades, sendo > que as duas primeiras seria você escrever bibliotecas em Perl ou em > Python, e elas estariam instaladas no S.O. e seriam acessíveis a > partir do Postgres via linguagens procedurais como PL/Perl [1] e > PL/Python [2] respectivamente. Em outras palavras as funções no banco > seriam "wrappers" em uma camada que chamariam as funções dentro das > libs que estariam em outra camada, como por exemplo: na PL você > poderia ter uma chamada que lê um registro de funcionário e passa ele > para um modulo Python externo que calcula o salário, um leitor curioso > pode ate ler sua função e ver "ah ele pega o João e calcula o salario > dele" mas não vai saber "o como é feito isso", ainda no caso do > Python, ele compila os arquivos .py para .pyc o que daria uma camada a > mais de ofuscação. > > Pense nesse modelo como as aplicações web fazem com os navegadores, > uma parte do código no navegador outra parte no backend e neste ponto > alguns podem falar, "ah mas no Javascript tem como ofuscar o código", > pois bem, o Postgres tem também a PL/V8, e aqui teríamos a terceira > possibilidade que é escrever a PL em Javascript e então utilizar > alguma biblioteca existente no ecosistema do Javascript para ofuscação > de código. > > Por conta dessa necessidade já houve casos propostos [3] na lista de > desenvolvedores do Postgres, então dê uma olhada para entender o > porquê isso não foi para frente ainda. > > Mesmo com tudo isso é importante deixar bem claro que ofuscar código > não é proteger código pois, afinal, o brilho do Sol até ofusca as > estrelas durante o dia, mas elas ainda estão lá. > > > [1] http://www.postgresql.org/docs/current/static/plperl.html > [2] http://www.postgresql.org/docs/current/static/plpython.html > [3] > http://www.postgresql.org/message-id/[email protected] > > > []s > -- > Dickson S. Guedes > mail/xmpp: [email protected] - skype: guediz > http://github.com/guedes - http://guedesoft.net > http://www.postgresql.org.br > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > bom dia, eu pensei em pl/pgsql, pois ele tem alguma compatibilidade com o oracle, e as funções poderia aproveitar uma parte. -- Douglas Fabiano Specht
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
