INFO: Como Visual Basic 3.0 identificadores de segurança definida pelo Microsoft Access

Traduções de Artigos Traduções de Artigos
Artigo: 105990 - Ver produtos para os quais este artigo se aplica.
Este artigo foi arquivado. Este artigo é oferecido "tal como está" e deixará de ser actualizado.
Expandir tudo | Reduzir tudo

Nesta página

Sumário

Visual Basic versão 3.0 inclui o motor de base de dados do Microsoft Access. Visual Basic contém a sintaxe para manipular uma base de dados do Microsoft Access no quase todas as forma que o Microsoft Access. Uma excepção principal está na área de segurança. Apenas o Microsoft Access pode definir ou modificar opções de segurança (tais como o ID de início de sessão e palavras-passe para o sistema) e definir ou modificar as permissões em objectos específicos numa determinada base de dados.

Visual Basic versão 3.0 contiver duas instruções (SetDataAccessOption e SetDefaultWorkspace) que permitem uma aplicação do Visual Basic para satisfazer o mecanismo de segurança que implementa o Microsoft Access e iniciem sessão utilizando código do Visual Basic. Utilizando estas instruções, pode ter as permissões concedidas a um determinado utilizador.

Este artigo explica os mecanismos de segurança aplicáveis ao Visual Basic versão 3.0 e o Programador de Visual Basic. As capacidades de segurança completa do Microsoft Access estão no âmbito deste artigo.

Para uma descrição completa das capacidades de segurança do Microsoft Access, consulte o seguinte artigo da base de dados de conhecimento:
122036WX1051: Assistente de segurança e documentação técnica App. Nota 2.0

Mais Informação

A segurança é implementada em duas partes:
  • Cada utilizador e grupo tem um código de ID (SID) de segurança exclusivo.
  • Esse código de SID é armazenado na base de dados juntamente com as permissões associadas para esse SID.
As duas secções fornecem os detalhes.

Cada utilizador e grupo tem o ID exclusivo de segurança (SID, Security Identifier)

No Microsoft Access, cada utilizador e grupo tem um ID de segurança (SID). O SID é uma cadeia binária que identifica o utilizador ou grupo. Quando um utilizador inicia sessão, se a partir do diálogo de início de sessão no Microsoft Access ou de código no Visual Basic (ilustrado posteriormente no artigo), o motor do Microsoft Access lê da tabela de base de dados SYSTEM.MDA MSysAccounts. Esta base de dados é criado apenas pelo Microsoft Access e outra (vazia) será criada se a cópia original é eliminada.

NOTA: Se SYSTEM.MDA original é eliminada acidentalmente, todos os SIDs exclusivos são perdidas. Por conseguinte, todas as capacidade de aceder a bases de dados protegidas também é perdida. Por este motivo, é uma boa ideia de cópias de segurança da base de dados e o ficheiro SYSTEM.MDA local quando as permissões foram definidas na base de dados.

Ao iniciar sessão, o utilizador fornece o nome de utilizador (não sensível a maiúsculas e minúsculas) e a palavra-passe (sensível a maiúsculas e minúsculas). Se o nome de utilizador e palavra-passe estiverem correctos, o SID do utilizador é obtido e guardado numa estrutura interna para o motor. A palavra-passe é utilizada apenas para validar o utilizador. A partir deste momento, quando o utilizador torna-se um utilizador validado, a palavra-passe não tem efeito sobre a segurança.

Segue-se um ponto de chave que diz respeito ao comportamento do Visual Basic. Por predefinição, o motor do Microsoft Access tenta validar o utilizador e palavra-passe de administrador e "" respectivamente. Visual Basic versão 3.0, sem qualquer código, enviará esta combinação de teclas para o motor do Microsoft Access por predefinição. Isto significa que, mesmo sem a utilização das instruções relacionadas com a segurança do Visual Basic, o programa Visual Basic irá obter admissão à base de dados, se o utilizador "Admin" do grupo administradores não teve a palavra-passe alterada da predefinição de nenhum ("").

Uma vez iniciada, é obtido o SID do utilizador. Este SID é utilizado para todas as operações subsequentes no motor Microsoft Access.

O SID É armazenado na base de dados SYSTEM.MDA

O SID é armazenado na própria base de dados. Por conseguinte, todas as permissões concedidas a um determinado utilizador ou grupo também são armazenadas na base de dados, associada ao SID exclusivo.

Chama outro ponto chave relativas ao comportamento do Visual Basic. O programa de Visual Basic obter acesso à base de dados e têm permissões totais, seeming ignorar o mecanismo de segurança do Microsoft Access se qualquer uma das seguintes condições for verdadeira:
  • O Programador de Visual Basic não tomou a localização do SYSTEM.MDA base de dados para a conta no código de programa.
  • O utilizador "Admin" não teve a palavra-passe alterada da predefinição de nenhum ("").
Isto ocorre devido ao comportamento predefinido do motor do Microsoft Access e do Visual Basic. O efeito combinado é permitir entrada para a base de dados e respectivos objectos por código do Visual Basic.

A lista dos tipos objecto no Microsoft Access são: tabela, consulta, formulário, relatório, macro e módulo. Destas opções, apenas os dois primeiros são acessíveis a partir do código Visual Basic, pelo que os outros podem ser omitidos desta explicação.

As seguintes duas secções explicam cada um dos dois do Visual Basic segurança relacionadas instruções (SetDataAccessOption e SetDefaultWorkspace). As duas instruções são concebidas para fornecer uma opção de SYSTEM.MDA ficheiros e entradas de início de sessão a uma base de dados do Microsoft Access, com a segurança definidas pelo Microsoft Access. Estas duas secções a seguir é uma secção que relaciona as duas instruções ao comportamento do motor Microsoft Access relativamente a segurança.

Declaração SetDataAccessOption--Comportamento e sintaxe

SetDataAccessOption tem os seguintes parâmetros:
   SetDataAccessOption option, value

   option is a numeric value with only one legal value (1).
				

Por exemplo:
   SetDataAccessOption 1, "E:\VBPROJ\MY.INI"
				

No ficheiro DATACONS.TXT fornecido na raiz do directório \VB, uma constante está definida para este valor:
   Global Const DB_OPTIONINIPATH = 1
				

SetDataAccessOption define o nome e caminho do ficheiro de inicialização (.ini) da aplicação. O ficheiro da aplicação .ini tem efeito apenas quando SetDataAccessOption é utilizado antes da funcionalidade de acesso de dados é carregada e inicializada. Depois de acesso a dados foi inicializado, esta definição não pode ser alterada sem primeiro a sair da aplicação. O valor é uma expressão de cadeia. Para a opção DB_OPTIONINIPATH, o argumento valor contém uma expressão de cadeia de fornecer o caminho e nome do ficheiro de inicialização (.ini) da aplicação. Ficheiros de inicialização são normalmente armazenados no directório \WINDOWS de um utilizador e tem o mesmo nome que o ficheiro executável, mas com uma extensão .ini. Utilize esta declaração apenas se o ficheiro de inicialização da aplicação tem um nome diferente ou estiver num directório diferente do directório \WINDOWS.

A instrução SetDataAccessOption não é necessária quando executar o projecto do Visual Basic no ambiente VB.EXE se o ficheiro VB.INI (no directório \WINDOWS) contém as seguintes linhas:

[Opções]
SystemDB=T:\ACCESS\SYSTEM.MDA
UtilityDB=T:\ACCESS\UTILITY.MDA

NOTA: a localização real do SYSTEM.MDA não é significativa fornecidos pelo Microsoft Access e do Visual Basic têm uma entrada apontando para SYSTEM.MDA que irão partilhar. A instrução SetDataAccessOption não é necessária se o ficheiro .exe da aplicação tem o seu próprio ficheiro .ini in a \WINDOWS e os ficheiros .exe e .ini partilham o mesmo nome.

Declaração SetDefaultWorkspace--Comportamento e sintaxe

SetDefaultWorkspace tem os seguintes parâmetros:
   SetDefaultWorkspace username, password
				

Se for deixada esta declaração de, Visual Basic enviará o equivalente a seguinte linha para o motor de base de dados do Microsoft Access que vem incluído com o Visual Basic:
   SetDefaultWorkspace "Admin" , ""
				

Esta declaração tem o efeito de obter um SID válido e obtenção de entrada para todos os objectos tabelas e consultas na base de dados.

Relação entre o Visual Basic e segurança do Microsoft Access

Para compreender a relação entre a segurança do Visual Basic e o Microsoft Access, tem de compreender o mecanismo de segurança do Microsoft Access. Eis uma explicação detalhada o benefício do Programador de Visual Basic que não utilizou o Microsoft Access extensivamente. Existe uma hierarquia de permissões no Microsoft Access. No nível superior, existem grupos. Contidos num determinado grupo são os utilizadores. Para conceder permissões selectivamente a utilizadores específicos, as todas as permissões primeiro devem ser desmarcadas ou removidas grupo dos utilizadores do. Apenas e, em seguida, em seguida, podem permissões serão concedidas ou revogadas para utilizadores individuais.

Permissões listadas para um utilizador individual são denominadas permissões explícitas. As permissões definidas para o grupo que contém a conta de utilizador são chamadas permissões implícita. Permissões implícitas têm prioridade sobre as permissões explícitas.

Pode utilizar o menu de segurança para definir permissões no Microsoft Access depois de uma base de dados foi aberta e o utilizador tenha iniciado. No menu ' segurança ', escolha as permissões para atribuir permissões em cada objecto na base de dados, que no Visual Basic significa apenas objectos de tabelas e consultas.

Por exemplo, se existir um grupo no Microsoft Access base de dados denominada analistas que contém os utilizadores João e a Sónia e pretende limitar apenas João para ler dados e conceder permissões Full Sara, siga estes passos:
  1. Inicie sessão no Microsoft Access como um utilizador no grupo de administradores. Por exemplo, introduza administração ou Rita.
  2. No menu ' segurança ', seleccione permissões (ALT S P).
  3. Tabela de objectos é o tipo predefinido. Seleccione o nome da tabela que pretende definir permissões no. Por exemplo, seleccione TestTbl.
  4. Defina a opção na moldura de utilizador/grupo a grupos. Em seguida, clique em lista da caixa de combinação para baixo e clique em analistas para seleccionar esse grupo.
  5. Desmarque todas as caixas de verificação para revogar a todas as permissões para o grupo completo.
  6. Repor o botão de opção lista de utilizadores e seleccione João. Desmarque as caixas de verificação das permissões do João.
  7. Seleccione a Sónia a partir da lista e seleccione a caixa de verificação permissões Full.
  8. Clique no botão atribuir para aplicar as alterações à tabela.
Neste ponto, assumir que tiver um programa do Visual Basic que contém o código seguinte no evento de carregamento formulário:
Sub Form_Load ()
   Dim db As database
   Dim ds As dynaset
   Dim scenario as integer

   scenario = 'insert a value between 1 and 4 here

   select case scenario
      case 1:
         ' Do nothing

      case 2:
         SetDefaultWorkspace "bob", "leftout"

      case 3:
         SetDataAccessOption 1, "E:\VB.INI"    ' not in \WINDOWS directory

      case 4:
         SetDataAccessOption 1, "E:\VB.INI"    ' not in \WINDOWS directory
         SetDefaultWorkspace "bob", "leftout"
   end select

   Set db = OpenDatabase("E:\DATACON\BASES\ACCESS11\ASAMPLE.MDB") ' point 1
   Set ds = db.CreateDynaset("TestTbl")                           ' point 2

   autoredraw = True   ' to make Print  statement persist on the form
   Print ds(0), ds(1)

End Sub
				

Seguem-se vários cenários para ilustrar a relação entre o Visual Basic e segurança do Microsoft Access:

CENÁRIO ONE: neste caso, não existe nenhuma referência à localização do ficheiro SYSTEM.MDA. O Windows e o motor do Microsoft Access não consegue localizar o ficheiro .ini com a secção [Options] listada anteriormente neste artigo. Por conseguinte, o SYSTEM.MDA é ignorado e assume a predefinição do Visual Basic para a combinação de utilizador e palavra-passe predefinida ("Admin", ""). No entanto, anteriormente, a palavra-passe predefinida para a administração do utilizador foi alterada para algo diferente de "". Além disso, todas as permissões foram revogadas para o grupo Administradores e o utilizador "Admin" no grupo de administradores. Por este motivo, ocorre o seguinte erro do Visual Basic altura 2:
Couldn't Read; no Read permission for Table or Query 'f)) '

Ter fechado a porta do cavalo para Visual Basic e qualquer aplicação do Visual Basic tentar ignorar inícios de sessão no ficheiro SYSTEM.MDA.

CENÁRIO TWO: neste caso, porque invocar a instrução SetDefaultWorkspace sem ter qualquer ponteiro para o ficheiro SYSTEM.MDA, o Microsoft Access Visual Basic motor hunts para o ficheiro SYSTEM.MDA e, não localizar, fornece o seguinte erro no ponto 0 o código:
Não foi possível localizar o ficheiro 'SYSTEM.MDA'

NOTA: Os erros que ocorrem em ambos os cenários de um e dois são iguais às ocorreria se o ficheiro SYSTEM.MDA foi movido, mudar o nome ou eliminado.

CENÁRIO TRIDIMENSIONAL: neste caso, indicam o motor do Visual Basic Microsoft Access onde reside o ficheiro SYSTEM.MDA mas não indicar uma combinação de utilizador e palavra-passe. Por conseguinte, novamente, Visual Basic fornece a combinação de utilizador e palavra-passe só seja conhecido ("Admin", ""), que já não é uma combinação válida, porque uma palavra-passe que adicionou a conta de utilizador de administração. Como resultado, Visual Basic apresenta o seguinte erro no ponto 1 o código:
Não uma conta válida ou palavra-passe.

CENÁRIO quatro: neste caso, tem de fornecer ambos os parâmetros correctamente. Por conseguinte, uma vez que atribuiu o João permissão "Ler dados", bem como "Definições de leitura" para permitir que o Microsoft Access Visual Basic motor para ler, a aplicação do Visual Basic imprime os primeiro dois campos no primeiro registo da tabela denominada TestTbl.

Se repetidamente os quatro cenários com o utilizador Sara, todos os vai ser o mesmo. No entanto, a Sónia pode continuar e modificar a estrutura da tabela e os dados bem. Lembre-se seleccionou primeiro os analistas de grupo e revogado todas as permissões. Em seguida, adicionou novamente todas as permissões para Sofia, mas apenas ler dados e definições de leitura foram adicionadas novamente ao João.

NOTA: O grupo Administradores tem um significado especial no que diz respeito à segurança. Isto aplica-se a qualquer utilizador nesse grupo. SID do grupo Administradores é armazenado no SYSTEM.MDA quando é criada uma base de dados. Como resultado, o grupo de Admins sempre terá permissão para alterar as permissões em todos os objectos na base de dados. Esta permissão não é possível efectuar imediatamente por qualquer pessoa. Esta permissão permanece, mesmo quando foram revogadas todas as permissões do grupo Administradores, e não é mostrado na caixa de diálogo permissões. Esta é outra razão para manter uma cópia de segurança e controlar qual SYSTEM.MDA estava a ser utilizado quando a base de dados foi criada.

Com OwnerAccess Option numa consulta SQL


Um último ponto de confusão possível gira à volta a utilização da seguinte expressão numa consulta SQL:
   ... With OwnerAccess Option
				

Por exemplo, analise este código:
   Sub Form_Load ()
      Dim db As Database
      Dim qd As querydef

      Set db = OpenDatabase("C:\ACCESS\DB1.MDB")

      ' Enter the following two lines of code as one, single line:

      Set qd = db.CreateQueryDef("myQD", "select * from [TableDetails]
         with owneraccess option ;")
      db.Close
   End Sub
				

Este código de resultado deste erro:
ID da base de dados inválido.

Isto acontece porque OwnerAccess se refere o proprietário da base de dados. O proprietário é o criador da base de dados. Por outras palavras, OwnerAccess refere-se para e palavra-passe de utilizador combinação o proprietário (SID exclusivo) armazenado na base de dados (BD1.MDB neste caso). No entanto, o código não contém as duas instruções necessárias para apontar para o ficheiro SYSTEM.MDA de uma base de dados protegida. Na realidade, neste caso, apenas a SetDefaultWorkspace instrução é essencial se encontra do ficheiro do ficheiro compilado .exe .ini que contém uma secção [Options] válida, no directório \WINDOWS.

O código utiliza o backdoor. -Não forneceu o SID do proprietário da base de dados para o motor exclusivo para o motor não sabe a nome e palavra-passe de combinação predefinida (Admin, "") do utilizador é o proprietário da base de dados. Mesmo que fica que o utilizador Admin é o proprietário da base de dados, sem ter de ler o ficheiro SYSTEM.MDA, o motor não consegue verificar desse facto para dá o erro.

Notas para utilizadores do Microsoft Access versão 2.0

Utilizar o recentemente lançada do Microsoft Jet 2.0/Visual Basic camada de compatibilidade 3.0, Visual Basic pode aceder a bases de dados do Microsoft Access versão 2.0. Seguem-se algumas notas para o ajudar a converter uma base de dados segura versão 1.1 num formato do Microsoft Access versão 2.0.

Se uma base de dados de uma versão do 1.x estiver protegida, permanecerá seguro se abrir com versão 1.x do Microsoft Access ou 2.0. No entanto, Microsoft Access versão 2.0 não pode ser utilizado para alterar ou adicionar as permissões na base de dados, mesmo pelo administrador, até que a base de dados é convertida para a versão 2.0.

Quando instala o Microsoft Access versão 2.0, cria seu próprio ficheiro de grupo de trabalho (SYSTEM.MDA). Se o Microsoft Access versão 2.0 for instalado no mesmo directório que versão 1.x, versão 1.x SYSTEM.MDA ficheiro será mudado de nome SYSTEM1X.MDA.

Para efectuar alterações a segurança da base de dados convertida, tem de utilizar uma versão 2.0 SYSTEM.MDA tem idênticos grupos e utilizadores (e PID idênticos) como SYSTEM.MDA original.

NOTA: O PID (Personal ID) no Microsoft Access versão 2.0 são o equivalente de PINs (números de ID pessoal) na versão 1.x

Para criar um grupo de trabalho seguro:
  1. Utilize a ferramenta do administrador do grupo de trabalho 2.0 para criar um novo grupo de trabalho. Este é um ficheiro versão 2.0 SYSTEM.MDA.
  2. Recriar todos os utilizadores e grupo de contas utilizando o mesmo nome e PID números que foram utilizados no Microsoft Access versão 1.x.
Para converter um 1.x segura da base de dados para o formato 2.0:

NOTA: No grupo de trabalho seguro, apenas os utilizadores com permissões Modificar estrutura para todos os objectos podem converter um formato de 1.x versão formato versão 2.0. Além disso, tem de atribuir permissões Modificar estrutura a base de dados de versão 1.x na utilizando o grupo de trabalho do versão 1.x do Microsoft Access versão 1.x.
  1. Certifique-se que ninguém está a utilizar a base de dados do versão 1.x.
  2. Inicie sessão no Microsoft Access 2.0 como um membro do grupo administradores que não seja administrador.
  3. No menu Ficheiro, seleccione o comando Converter base de dados.
  4. Seleccione a versão de dados de 1.x que pretende converter. Vai ser-lhe o nome de base de dados 2.0 versão.

    NOTA: O comando Converter base de dados fará escolher um novo nome para a base de dados. Isto permite-lhe manter uma cópia de segurança cópia da base de dados versão 1.x, como depois de ter convertido uma base de dados a partir da versão 1.x para a versão 2.0 que não pode ser novamente convertido versão 1.x.
  5. Peça aos utilizadores a associar-se o novo grupo de versão 2.0 trabalho (SYSTEM.MDA) utilizando a ferramenta do administrador do grupo de trabalho.

    NOTA: É possível também efectuar este procedimento modificando o ficheiro MSACC20.INI no directório do Windows. Na secção [Options] do ficheiro, altere a entrada SystemDB para apontar para a versão 2.0 SYSTEM.MDA ficheiro. A secção [Options] do ficheiro será semelhante ao exemplo que se segue:
          [Options]
          SystemDB=<microsoft access path>\SYSTEM.MDA
    
    						

Pontos-chave a lembrar

  1. Apenas o Microsoft Access pode criar e modificar o ficheiro SYSTEM.MDA.
  2. O ficheiro SYSTEM.MDA contém SID exclusivo utilizado numa base de dados com permissões para ordenar que é que para o Microsoft Access motor para impor essas permissões. O SID é obtido, fornecendo o motor do Microsoft Access com um utilizador válido e combinação de palavra-passe, a partir do qual obtém o SID exclusivo que o motor armazena na memória para reforçar a segurança de uma base de dados aberta.
  3. É necessário ser apontado para a localização desactivar o ficheiro SYSTEM.MDA para obter acesso para bases de dados com segurança e permissões implementadas o Microsoft Access e do Visual Basic.
  4. Existe uma porta do cavalo disponíveis para o programa de aplicação do Visual Basic se a palavra-passe para a predefinição de utilizador no grupo Administradores (denominado administrador) não é alterada da predefinição nenhum ("").
  5. Se a expressão "Com OwnerAccess Option" for utilizada numa consulta SQL de um método CreateQueryDef, CreateDynaset ou CreateSnapshot, um ponteiro para o ficheiro SYSTEM.MDA tem de existir. Mesmo esteja a utilizar a porta do cavalo (a combinação de utilizador e palavra-passe predefinida de administração e "") e não parece necessita SYSTEM.MDA, quando utiliza "Com OwnerAccess Option" numa consulta SQL, o motor deve consultar o ficheiro SYSTEM.MDA para corresponder ao SID do proprietário (autor) da base de dados para o utilizador com sessão iniciada.
  6. As combinações de utilizador e palavra-passe de início de sessão válidas são armazenadas no ficheiro SYSTEM.MDA mas as permissões são armazenadas na base de dados (.mdb ficheiro) própria. Um código exclusivo (SID) é extraído a partir de SYSTEM.MDA utilizando um utilizador válido e combinação de palavra-passe, fornecida para o motor do Microsoft Access, a caixa de diálogo início de sessão do Microsoft Access ou o código do Visual Basic.

Propriedades

Artigo: 105990 - Última revisão: 5 de fevereiro de 2014 - Revisão: 2.0
A informação contida neste artigo aplica-se a:
  • Microsoft Visual Basic 3.0 Professional Edition
  • Microsoft Visual Basic 3.0 Professional Edition
Palavras-chave: 
kbnosurvey kbarchive kbmt kbinfo KB105990 KbMtpt
Tradução automática
IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine translation ou MT), não tendo sido portanto revisto ou traduzido por humanos. A Microsoft tem artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais. O objectivo é simples: oferecer em Português a totalidade dos artigos existentes na base de dados do suporte. Sabemos no entanto que a tradução automática não é sempre perfeita. Esta pode conter erros de vocabulário, sintaxe ou gramática? erros semelhantes aos que um estrangeiro realiza ao falar em Português. A Microsoft não é responsável por incoerências, erros ou estragos realizados na sequência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza actualizações frequentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 105990

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com