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
