GARANTIR DESCONTO

Fórum Apagar o SYSDBA #49141

02/02/2005

0

Olá pessoal.
Se eu apagar o usuario SYSDBA e criar outro usuario do meu servidor FireBird e outra pessoa pegar meu banco e quiser abrir com um servidor com o usuario SYSDBA senha masterkey, ela vai conseguir?
Pergunto isso pq eu já fiz isso com um banco do interbase.:D
Agradeço antecipadamente.


Flaviosan

Flaviosan

Responder

Posts

02/02/2005

Gandalf.nho

Sim, independente de qual usuário criar o banco, O SYSDBA sempre poderá abri-lo


Responder

Gostei + 0

02/02/2005

Vinicius2k

Além disso, vale lembrar que o SYSDBA não pode ser excluído... apenas pode ter sua senha alterada.

T+


Responder

Gostei + 0

02/02/2005

Afarias

Apenas pode ter sua senha alterada.


pode e DEVE

;-)


T+


Responder

Gostei + 0

03/02/2005

Martins

Ei vcs já viram o novo SEFIP for Windows, para calculo de FGTS, ele vem com o BD Interbase 6, e tem uma paradinha bacana, pois mesmo q vc copie para outro PC o usuáio SYSBDA não tem acesso a nada no banco, ou seja ele não consegue acessar nada e caso alguém consiga alterar algo, o sistema informa q houve violação na base de dados. vc podem baixar ele no site da caixa nesse endereço:[url]http://www1.caixa.gov.br/download/asp/download.asp?scateg=14[/url]

Vejam lá e depois me digam o q vcs acham.

Martins


Responder

Gostei + 0

03/02/2005

Afarias

Não há proteção alguma dos dados na base. Qualquer 1 continua podendo abrir o banco de dados, seja local ou em outro computador.

O q eles adicionaram (além do velho truque pra não permitir acesso do SYSDBA, já mencionado neste fórum) foi algum tipo de ´detecção´ do uso da base por um ´agente externo´

Não observei a fundo mas detecção deve ser realizada guardando o estado do arquivo (banco) sempre após sua última utilização, por exemplo, guardando os valores das últimas OIT, OTA, etc... ou mesmo guargando um HASH (MD5 por exemplo) do arquivo de dados.

A idéia foi nessa linha acredito.

Sendo assim, ele não permite o uso dessa base ´alterada´ no sistema.

Bom -- ´não permite´ entre aspas... facilmente essa ´segurança´ é burlada (como já fiz aqui)

Além do mais, fizeram algo q considero uma grande falha... todos os códigos do banco de dados (procedures -- e q não são poucos! uns 300) estão lá para qualquer 1 ver -- e alterar se desejar, mudando assim o comportamento do sistema, permitindo por exemplo entrada de valores ´burlados´.

Mas creio q haja uma validação disso num servidor central depois né? Deve ter...


T+


Responder

Gostei + 0

04/02/2005

Flaviosan

Nossa, valeu pessoal. Tiraram todas as minhas duvidas.
não sei se vcs já sabem, mas o interbase 7.5 tem um recurso chamado Embedded Database User Authentication (EUA) que permite que as contas de usuario sejam armazenadas dentro do proprio banco de dados. Uma mão na roda. Será que o firebird tem, ou vai ter algo parecido com isso? Tomara. :)
Obrigado pelos esclarecimentos.


Responder

Gostei + 0

04/02/2005

Gandalf.nho

não sei se vcs já sabem, mas o interbase 7.5 tem um recurso chamado Embedded Database User Authentication (EUA) que permite que as contas de usuario sejam armazenadas dentro do proprio banco de dados. Uma mão na roda. Será que o firebird tem, ou vai ter algo parecido com isso?


Está previsto para a futura versão do Firebird.


Responder

Gostei + 0

04/02/2005

Martins

Não há proteção alguma dos dados na base. Qualquer 1 continua podendo abrir o banco de dados, seja local ou em outro computador. O q eles adicionaram (além do velho truque pra não permitir acesso do SYSDBA, já mencionado neste fórum) foi algum tipo de ´detecção´ do uso da base por um ´agente externo´ Não observei a fundo mas detecção deve ser realizada guardando o estado do arquivo (banco) sempre após sua última utilização, por exemplo, guardando os valores das últimas OIT, OTA, etc... ou mesmo guargando um HASH (MD5 por exemplo) do arquivo de dados. A idéia foi nessa linha acredito. Sendo assim, ele não permite o uso dessa base ´alterada´ no sistema. Bom -- ´não permite´ entre aspas... facilmente essa ´segurança´ é burlada (como já fiz aqui) Além do mais, fizeram algo q considero uma grande falha... todos os códigos do banco de dados (procedures -- e q não são poucos! uns 300) estão lá para qualquer 1 ver -- e alterar se desejar, mudando assim o comportamento do sistema, permitindo por exemplo entrada de valores ´burlados´. Mas creio q haja uma validação disso num servidor central depois né? Deve ter... T+


Concordo com vc [b]afarias[b], eu tb consegui entrar e ver algumas coisas, e dei uma olhada nas SP do banco, certa vez imprimi um artigo lá no firebase q mostra como proteger as procedures, triggers, bem legal, talvez eles não se importem muito com isso.

Martins


Responder

Gostei + 0

04/02/2005

Afarias

|Está previsto para a futura versão do Firebird

Exato. No Vulcan já foi implementado, além de outros ´incrementos´ no sistema de controle de usuários.

O Vulcan, para os q não conhecem é um projeto ´paralelo´ desenvolvido pela IBPhoenix (o grupo q lidera o projeto Firebird) que deve ser o futuro do Firebird -- agregando ao SGBD uma reformulação da arquitetura e ´funcionalidades´ como suporte multi-processamento (SMP) e a plataforma 64bits


T+


Responder

Gostei + 0

04/02/2005

Afarias

Concordo com vc afarias, eu tb consegui entrar e ver algumas coisas, e dei uma olhada nas SP do banco, certa vez imprimi um artigo lá no firebase q mostra como proteger as procedures, triggers, bem legal, talvez eles não se importem muito com isso.


Mas deviam. Se eles tiveram o trabalho de criar um ´dispositivo´ com a intenção de evitar q ´manupulassem´ a base de dados, deviam ter cuidados mais básicos como retirar o código de procedimentos e triggers.

Isso me parece mais pouca experiência com o Interbase. Na minha opnião.


T+


Responder

Gostei + 0

Utilizamos cookies para fornecer uma melhor experiência para nossos usuários, consulte nossa política de privacidade.

Aceitar