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

Traduções deste artigo Traduções deste artigo
ID do artigo: 105990 - Exibir os produtos aos quais esse artigo se aplica.
Este artigo foi arquivado. É oferecido "como está" e não será mais atualizado.
Expandir tudo | Recolher tudo

Neste artigo

Sumário

Visual Basic versão 3.0 inclui o mecanismo de banco de dados do Microsoft Access. Visual Basic contém a sintaxe para manipular um banco de dados do Microsoft Access em quase todas as formas que o Microsoft Access pode. Uma exceção principal está na área de segurança. Somente o Microsoft Access pode definir ou modificar opções de segurança (tais como identificações de logon e senhas para o sistema) e definir ou modificar permissões em objetos específicos em um determinado banco de dados.

Visual Basic versão 3.0 contém duas instruções (SetDataAccessOption e SetDefaultWorkspace) que permitem que um aplicativo Visual Basic para satisfazer o mecanismo de segurança que implementa o Microsoft Access e façam logon usando código do Visual Basic. Usando essas instruções, você pode obter as permissões concedidas a um determinado usuário.

Este artigo explica os mecanismos de segurança que se aplicam a versão do Visual Basic 3.0 e o programador de Visual Basic. Os recursos de segurança inteira do Microsoft Access são além do escopo deste artigo.

Para uma descrição completa dos recursos de segurança do Microsoft Access, consulte o seguinte artigo do Knowledge Base:
122036WX1051: Assistente de segurança e documento App. Observação 2.0

Mais Informações

A segurança é implementada em duas partes:
  • Cada usuário e grupo tem um código de identificação (SID) de segurança exclusiva.
  • Esse código de SID é armazenado no banco de dados juntamente com as permissões associadas para esse SID.
As duas próximas seções fornecem os detalhes.

Cada usuário e grupo possui a identificação exclusiva de segurança (SID)

No Microsoft Access, cada usuário e grupo tem uma identificação de segurança (SID). O SID é uma seqüência de caracteres binária que identifica exclusivamente o usuário ou grupo. Quando um usuário faz logon, se na caixa de diálogo logon no Microsoft Access ou de código no Visual Basic (ilustrado mais adiante neste artigo), o mecanismo do Microsoft Access lê da tabela do banco de dados SYSTEM.MDA MSysAccounts. Este banco de dados é criado somente pelo Microsoft Access e um novo nome (vazio) será criado se a cópia original é excluída.

Observação: Se SYSTEM.MDA original for acidentalmente excluído, todos os SIDs exclusivos são perdidas. Portanto, todas as capacidade de obter acesso a bancos de dados protegidos também é perdida. Portanto, é uma boa idéia para fazer backup os banco de dados e o arquivo SYSTEM.MDA no lugar quando as permissões foram definidas no banco de dados.

Ao fazer logon, o usuário fornece o nome de usuário (não diferencia maiúsculas de minúsculas) e a senha (diferencia maiúsculas de minúsculas). Se o nome de usuário e senha estão corretos, o SID do usuário é recuperado e salvo em uma estrutura interna para o mecanismo de. A senha é usada somente para validar o usuário. Desse ponto em diante, depois que o usuário torna-se um usuário validado, a senha não tem efeito na segurança.

Aqui está um ponto-chave que pertencem ao comportamento do Visual Basic. Por padrão, o mecanismo do Microsoft Access tenta validar o usuário e a senha de administrador e "" respectivamente. Visual Basic versão 3.0, sem qualquer código, enviará esta combinação de teclas para o mecanismo do Microsoft Access por padrão. Isso significa que, mesmo sem o uso das instruções do Visual Basic relacionados à segurança, o programa do Visual Basic obterá admissão para o banco de dados, se o usuário "Admin" do grupo Administradores não teve sua senha alterada do padrão de nenhuma ("").

Após o logon, o SID do usuário é recuperado. Esse SID é usado para todas as operações subseqüentes dentro o mecanismo do Microsoft Access.

O SID É armazenado no banco de dados SYSTEM.MDA

O SID é armazenado no próprio banco de dados. Portanto, todas as permissões concedidas a um determinado usuário ou grupo também são armazenadas no banco de dados, associado ao SID exclusivo.

Isso abre outro ponto-chave relativos ao comportamento do Visual Basic. O programa Visual Basic irá obter entrada para o banco de dados e têm permissões totais, seeming ignorar o mecanismo de segurança do Microsoft Access se qualquer uma das seguintes opções for verdadeira:
  • O programador de Visual Basic não assumiu o local do SYSTEM.MDA banco de dados em consideração no código de programa.
  • O usuário "Admin" ainda não tenha sua senha alterada do padrão de nenhuma ("").
Isso ocorre devido ao comportamento padrão do mecanismo do Microsoft Access e Visual Basic. O efeito combinado é permitir a entrada para o banco de dados e seus objetos, o código do Visual Basic.

A lista dos tipos de objeto no Microsoft Access são: tabela, consulta, formulário, relatório, macro e módulo. Dessas, somente os dois primeiros são acessíveis no código do Visual Basic, para que os outros podem ser omitidos dessa explicação.

Duas seções a seguir explicam cada um dos dois Visual Basic segurança relacionadas instruções (SetDataAccessOption e SetDefaultWorkspace). As duas instruções são projetadas para fornecer uma escolha de SYSTEM.MDA arquivos e entradas de logon para um banco de dados do Microsoft Access, com segurança definida pelo Microsoft Access. Essas duas seções a seguir é uma seção que relaciona as duas instruções para o comportamento do mecanismo do Microsoft Access com relação à segurança.

Declaração de SetDataAccessOption--Sintaxe e o comportamento

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 arquivo DATACONS.TXT fornecido na raiz do diretório \VB, uma constante é definida para este valor:
   Global Const DB_OPTIONINIPATH = 1
				

SetDataAccessOption define o nome e caminho do arquivo de inicialização (inicialização) do aplicativo. Arquivo de inicialização do aplicativo tem efeito somente quando SetDataAccessOption é usado antes da funcionalidade de acesso a dados é carregada e inicializada. Depois que o acesso a dados tiver sido inicializado, essa configuração não pode ser alterada sem primeiro saindo do aplicativo. O valor é uma expressão em seqüência. Para a opção DB_OPTIONINIPATH, o argumento de valor contém uma expressão de seqüência de caracteres fornecendo o caminho e nome do arquivo de inicialização (inicialização) do aplicativo. Arquivos de inicialização geralmente são armazenados no diretório \Windows do usuário e tenham o mesmo nome que o arquivo executável, mas com uma extensão de inicialização. Use esta instrução somente se o arquivo de inicialização do aplicativo tem um nome diferente ou está em um diretório diferente do diretório \Windows.

A instrução SetDataAccessOption não é necessário quando você executar o projeto Visual Basic no ambiente VB.EXE se o arquivo VB.INI (na pasta \Windows) contém as seguintes linhas:

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

Observação: o local real do SYSTEM.MDA não é significativo desde o Microsoft Access e Visual Basic tem uma entrada apontando para SYSTEM.MDA elas compartilharão. A instrução SetDataAccessOption não é necessária se o arquivo .exe do aplicativo tem seu próprio arquivo .ini na \Windows e os arquivos .exe e .ini compartilham o mesmo nome.

Declaração de SetDefaultWorkspace--Sintaxe e o comportamento

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

Se esta instrução for deixada check-out, Visual Basic enviará o equivalente a seguinte linha para o mecanismo de banco de dados do Microsoft Access que acompanha o Visual Basic:
   SetDefaultWorkspace "Admin" , ""
				

Essa instrução tem o efeito de obter um SID válido e obtenção de entrada a todos os objetos tabela e consulta no banco de dados.

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

Para compreender a relação entre segurança Visual Basic e o Microsoft Access, você deve compreender o mecanismo de segurança do Microsoft Access. Aqui está uma explicação detalhada para o benefício do programador de Visual Basic que não tenha usado o Microsoft Access extensivamente. Há uma hierarquia de permissões no Microsoft Access. No nível superior, não há grupos. Contido em um determinado grupo são usuários. Para conceder permissões seletivamente a usuários específicos, todas as permissões primeiro devem ser desmarcadas ou removidas do grupo de usuários. Somente e, em seguida, em seguida, podem permissões ser concedidas ou revogadas para usuários individuais.

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

Você pode usar o menu segurança para definir permissões no Microsoft Access após a um banco de dados foi aberto e o usuário tiver feito logon. No menu segurança, escolha permissões para atribuir permissões em cada objeto no banco de dados, que significa que somente os objetos de tabela e consulta no Visual Basic.

Por exemplo, se houver um grupo no Microsoft Access banco de dados denominado analistas contendo os usuários Bob e Sue e você deseja limitar apenas Bob para ler dados e conceder permissões inteira dedicada, execute estas etapas:
  1. Faça logon no Microsoft Access como um usuário no grupo de administradores. Por exemplo, digite administrador ou Fred.
  2. No menu segurança, escolha permissões (ALT S P).
  3. Objetos de tabela são o tipo padrão. Selecione o nome da tabela que você deseja definir permissões em. Por exemplo, selecione TestTbl.
  4. Defina a opção no quadro de usuários e grupos a grupos. Em seguida, clique em lista da caixa de combinação para baixo e clique em analistas para selecionar esse grupo.
  5. Desmarque todas as caixas de seleção para revogar todas as permissões para o grupo inteiro.
  6. Alterar o botão de opção da lista de volta para os usuários e selecione Bob. Desmarque as caixas de seleção para todas as permissões de Bob.
  7. Selecione Sue da lista e marque a caixa de seleção permissões Full.
  8. Clique no botão atribuir para aplicar as alterações à tabela.
Neste ponto, que você tenha um programa do Visual Basic que contém o seguinte código no evento de carregamento de 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
				

Aqui estão vários cenários para ilustrar a relação entre Visual Basic e do Microsoft Access Security:

CENÁRIO ONE: nesse caso, não é nenhuma referência ao local do arquivo SYSTEM.MDA. Windows e o mecanismo do Microsoft Access não consegue localizar o arquivo .ini com a seção [Options] listada anteriormente neste artigo. Portanto, o SYSTEM.MDA será ignorado e padrão do Visual Basic para sua combinação de usuário e senha padrão ("Admin", ""). No entanto, anteriormente, a senha padrão para o administrador do usuário foi alterada para algo diferente de "". Além disso, todas as permissões foram revogadas para o grupo Administradores e o usuário "Admin" no grupo de administradores. Portanto, ocorrerá o seguinte erro de Visual Basic no ponto 2:
Couldn't Read; no Read permission for Table or Query 'f)) '

Você fechou a back door para Visual Basic e qualquer aplicativo do Visual Basic tentando ignorar logons no arquivo SYSTEM.MDA.

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

Observação: Os erros que ocorrem em ambos os cenários de um e dois são os mesmos como ocorreria se o arquivo SYSTEM.MDA foi movido, renomeado ou excluído.

CENÁRIO tres: neste caso, você informar o mecanismo do Visual Basic Microsoft Access onde reside o arquivo SYSTEM.MDA mas não fornece uma combinação de usuário e senha. Portanto, novamente, Visual Basic fornece a combinação de usuário e senha somente ele sabe ("Admin", ""), que não é mais uma combinação válida, pois você adicionou uma senha à conta de usuário Admin. Como resultado, o Visual Basic fornece o seguinte erro em 1 ponto o código:
Não é um válido de conta ou senha.

CENÁRIO quatro: neste caso, você fornecer os dois parâmetros corretamente. Portanto, porque você deu permissão "Ler dados" Bob, bem como "Ler definições" para permitir que o Visual Basic Microsoft mecanismo para ler, o aplicativo Visual Basic imprime os primeiros dois campos no primeiro registro da tabela chamada TestTbl.

Se você repetir os quatro cenários com o usuário dedicada, todos seriam as mesmas. No entanto, Sue poderia ir além e modificar a estrutura da tabela e também os dados. Lembre-se, primeiro os analistas de grupo selecionado e revogado todas as permissões. Em seguida, você adicionou novamente todas as permissões para Sue, mas somente ler dados e definições de leitura foram adicionadas ao Bob.

Observação: O grupo de administradores tem significado especial com relação à segurança. Isso se aplica a qualquer usuário em que grupo. SID do grupo Administradores é armazenado no SYSTEM.MDA quando um banco de dados é criado. Como resultado, o grupo de administradores sempre terá permissão para alterar as permissões em todos os objetos naquele banco de dados. Esta permissão não pode ser retirada fora por qualquer pessoa. Esta permissão permanece mesmo quando todas as permissões foram revogadas do grupo Administradores, e ele não será exibido na caixa de diálogo permissões. Isso é outro motivo para manter um backup e controlar qual SYSTEM.MDA estava em uso quando o banco de dados foi criado.

Com a opção OwnerAccess em uma consulta SQL


Um último ponto de possível confusão emprega o uso da seguinte frase em uma consulta SQL:
   ... With OwnerAccess Option
				

Por exemplo, verifique 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
				

Esse código resulta neste erro:
Identificação de banco de dados inválida.

Isso ocorre porque OwnerAccess refere-se ao proprietário do banco de dados. O proprietário é o criador do banco de dados. Em outras palavras, OwnerAccess refere-se a usuário e senha combinação do proprietário do (SID exclusivo) armazenado no banco 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 arquivo SYSTEM.MDA de um banco de dados protegido. Na verdade, nesse caso, apenas a instrução SetDefaultWorkspace é essencial se .ini arquivo do arquivo exe compilado que contém uma seção [Options] válida, está na pasta \Windows.

O código usa a porta dos fundos. Ele não tenha fornecido o SID exclusivo do proprietário do banco de dados para o mecanismo para que o mecanismo não saiba a combinação de nome e senha padrão (Admin, "") do usuário é o proprietário do banco de dados. Mesmo que o usuário Admin é o proprietário do banco de dados, sem ter que ler o arquivo SYSTEM.MDA, o mecanismo não pode verificar esse fato, portanto, ele permite que o erro.

Observações para os usuários do Microsoft Access versão 2.0

Usando o lançadas recentemente Microsoft Jet 2.0/Visual Basic 3.0 camada de compatibilidade, Visual Basic pode obter acesso a bancos de dados do Microsoft Access versão 2.0. Abaixo estão algumas anotações para ajudar você a converter um banco de dados seguro versão 1.1 no formato Microsoft Access versão 2.0.

Se um banco de dados do versão 1.x estiver protegido, ele permanecerá seguro se você abri-lo com o Microsoft Access versão 1.x ou 2.0. No entanto, versão 2.0 do Microsoft Access não pode ser usado para alterar ou adicionar permissões no banco de dados, mesmo pelo administrador, até que o banco de dados é convertido para a versão 2.0.

Quando você instala o Microsoft Access versão 2.0, ele cria seu próprio arquivo de grupo de trabalho (SYSTEM.MDA). Se o Microsoft Access versão 2.0 é instalado no mesmo diretório como versão 1.x, o arquivo do versão 1.x SYSTEM.MDA será renomeado SYSTEM1X.MDA.

Para fazer alterações à segurança de um banco de dados convertido, você deve usar uma versão 2.0 SYSTEM.MDA tem idênticos grupos e usuários (e PIDs idênticos) como SYSTEM.MDA original.

Observação: PIDs (particulares IDs) no Microsoft Access versão 2.0 são o equivalente de PINs (números de identificação pessoal) na versão 1.x

Para criar um grupo de trabalho seguro:
  1. Use a ferramenta de administrador do grupo de trabalho 2.0 para criar um novo grupo de trabalho. Este é um arquivo de versão 2.0 SYSTEM.MDA.
  2. Recriar todos os usuários e contas usando os mesmos nomes e identificação de grupo números que foram usados no Microsoft Access versão 1.x.
Para converter um banco de dados 1.x seguro para o formato 2.0:

Observação: Em um grupo de trabalho seguro, somente os usuários com permissões Modificar Design para todos os objetos podem converter um formato da versão 1.x para 2.0 formato. Além disso, você deve atribuir permissões Modificar Design para o banco de dados versão 1.x no usando o grupo de trabalho do versão 1.x do Microsoft Access versão 1.x.
  1. Verifique se que ninguém está usando o banco de dados versão 1.x.
  2. Faça logon no Microsoft Access 2.0 como um membro do grupo Administradores que não seja o usuário Admin.
  3. No menu ' arquivo ', escolha o comando Converter banco de dados.
  4. Selecione 1.x o banco de dados versão que você deseja converter. Você será solicitado o nome de banco de dados 2.0 versão.

    Observação: O comando Converter banco de dados irá forçá-lo para escolher um novo nome para o banco de dados. Isso lhe permite manter uma cópia backup do banco de dados do versão 1.x, como quando você tiver convertido um banco de dados versão 1.x para 2.0 que você não pode convertê-lo novamente em versão 1.x.
  5. Que os usuários associar o grupo de trabalho novo da versão 2.0 (SYSTEM.MDA) usando a ferramenta de administrador do grupo de trabalho.

    Observação: Você também pode realizar isso modificando o arquivo MSACC20.INI na pasta do Windows. Na seção [Options] do arquivo, altere a entrada SystemDB para apontar para a versão 2.0 SYSTEM.MDA arquivo. A seção [Options] do arquivo será semelhante ao exemplo a seguir:
          [Options]
          SystemDB=<microsoft access path>\SYSTEM.MDA
    
    						

Pontos-chave

  1. Somente o Microsoft Access pode criar e modificar o arquivo SYSTEM.MDA.
  2. O arquivo SYSTEM.MDA contém o SID exclusivo usado em um banco de dados com permissões para classificar a saída quem é que para o Microsoft Access mecanismo para aplicar essas permissões. O SID é obtido, fornecendo o mecanismo do Microsoft Access com um usuário válido e senha combinação, de que ele obtém o SID exclusivo que o mecanismo armazena na memória para impor segurança em um banco de dados aberto.
  3. Microsoft Access e Visual Basic precisam ser apontado para o local do arquivo SYSTEM.MDA para obter acesso a bancos de dados ter segurança e permissões implementadas.
  4. Há uma porta dos fundos disponíveis para o programa de aplicativo do Visual Basic caso a senha para o padrão de usuário no grupo Administradores (chamado Admin) não é alterada do padrão nenhum ("").
  5. Se a frase "Com OwnerAccess opção" é usada na consulta SQL de um método CreateQueryDef, CreateDynaset ou CreateSnapshot, um ponteiro para o arquivo SYSTEM.MDA deve existir. Mesmo se você estiver usando a back door (a combinação de usuário e senha padrão do administrador e "") e parecem não precisa SYSTEM.MDA, quando você usar "Com OwnerAccess opção" em uma consulta SQL, o mecanismo deve consulte o arquivo SYSTEM.MDA para coincidir com o SID do proprietário (criador) do banco de dados para o usuário que fez logon.
  6. As combinações de usuário e senha de logon válidas são armazenadas no arquivo SYSTEM.MDA mas as permissões são armazenadas no banco de dados (.mdb arquivo) propriamente dito. Uma chave exclusiva (SID) é extraída do SYSTEM.MDA usando um usuário válido e uma combinação de senha, fornecido para o mecanismo do Microsoft Access, a caixa de diálogo logon no Microsoft Access ou o código no Visual Basic.

Propriedades

ID do artigo: 105990 - Última revisão: segunda-feira, 21 de outubro de 2013 - 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 traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 105990

Submeter comentários

 

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