Direitos de segurança e acesso de arquivos

Como os arquivos são objetos protegíveis, o acesso a eles é regulamentado pelo modelo de controle de acesso que rege o acesso a todos os outros objetos protegíveis no Windows. Para obter uma explicação detalhada desse modelo, consulte Controle de Acesso.

Você pode especificar um descritor de segurança para um arquivo ou diretório ao chamar a função CreateFile, CreateDirectory ou CreateDirectoryEx . Se você especificar NULL para o parâmetro lpSecurityAttributes , o arquivo ou diretório receberá um descritor de segurança padrão. As ACL (listas de controle de acesso) no descritor de segurança padrão para um arquivo ou diretório são herdadas de seu diretório pai. Observe que um descritor de segurança padrão é atribuído somente quando um arquivo ou diretório é recém-criado e não quando é renomeado ou movido.

Para recuperar o descritor de segurança de um arquivo ou objeto de diretório, chame a função GetNamedSecurityInfo ou GetSecurityInfo . Para alterar o descritor de segurança de um arquivo ou objeto de diretório, chame a função SetNamedSecurityInfo ou SetSecurityInfo .

Os direitos de acesso válidos para arquivos e diretórios incluem os direitos de acesso DELETE, READ_CONTROL, WRITE_DAC, WRITE_OWNER e SYNCHRONIZEstandard. A tabela em Constantes de Direitos de Acesso a Arquivos lista os direitos de acesso específicos para arquivos e diretórios.

Embora o direito de acesso SYNCHRONIZE seja definido dentro da lista de direitos de acesso padrão como o direito de especificar um identificador de arquivo em uma das funções de espera, ao usar operações de E/S de arquivo assíncrona, você deve aguardar no identificador de evento contido em uma estrutura OVERLAPPED configurada corretamente em vez de usar o identificador de arquivo com o acesso SYNCHRONIZE direito para sincronização.

Veja a seguir os direitos de acesso genéricos para arquivos e diretórios.

Direito do acesso	Descrição
FILE_GENERIC_EXECUTE	FILE_EXECUTE FILE_READ_ATTRIBUTES STANDARD_RIGHTS_EXECUTE SINCRONIZAR
FILE_GENERIC_READ	FILE_READ_ATTRIBUTES FILE_READ_DATA FILE_READ_EA STANDARD_RIGHTS_READ SINCRONIZAR
FILE_GENERIC_WRITE	FILE_APPEND_DATA FILE_WRITE_ATTRIBUTES FILE_WRITE_DATA FILE_WRITE_EA STANDARD_RIGHTS_WRITE SINCRONIZAR

 

Windows compara os direitos de acesso solicitados e as informações no token de acesso do thread com as informações no descritor de segurança do arquivo ou do objeto de diretório. Se a comparação não proibir que todos os direitos de acesso solicitados sejam concedidos, um identificador para o objeto será retornado ao thread e os direitos de acesso serão concedidos. Para obter mais informações sobre esse processo, consulte Interação entre threads e objetos protegíveis.

Por padrão, a autorização para acesso a um arquivo ou diretório é controlada estritamente pelas ACLs no descritor de segurança associado a esse arquivo ou diretório. Em particular, o descritor de segurança de um diretório pai não é usado para controlar o acesso a nenhum arquivo ou diretório filho. O direito de FILE_TRAVERSEaccess pode ser imposto removendo o BYPASS_TRAVERSE_CHECKINGprivilege dos usuários. Isso não é recomendado no caso geral, pois muitos programas não lidam corretamente com erros de passagem de diretório. O principal uso para o acesso FILE_TRAVERSE diretamente em diretórios é habilitar a conformidade com determinados padrões IEEE e ISO POSIX quando a interoperabilidade com sistemas Unix é um requisito.

O modelo de segurança Windows fornece uma maneira de um diretório filho herdar ou ser impedido de herdar um ou mais ACEs no descritor de segurança do diretório pai. Cada ACE contém informações que determinam como ela pode ser herdada e se terá um efeito sobre o objeto de diretório herdado. Por exemplo, alguns ACEs herdados controlam o acesso ao objeto de diretório herdado e são chamados de ACEs eficazes. Todas as outras ACEs são chamadas de ACEs somente herdadas.

O modelo de segurança Windows também impõe a herança automática de ACEs a objetos filho de acordo com as regras de herança ace. Essa herança automática, juntamente com as informações de herança em cada ACE, determina como as restrições de segurança são passadas para baixo na hierarquia de diretório.

Observe que você não pode usar um ACE negado pelo acesso para negar apenas GENERIC_READ ou apenas GENERIC_WRITE acesso a um arquivo. Isso ocorre porque, para objetos de arquivo, os mapeamentos genéricos para GENERIC_READ ou GENERIC_WRITE incluem o direito de acesso SYNCHRONIZE . Se uma ACE negar GENERIC_WRITE acesso a um administrador e o administrador solicitar GENERIC_READ acesso, a solicitação falhará porque a solicitação incluirá implicitamente o acesso SYNCHRONIZE , que é implicitamente negado pelo ACE e vice-versa. Em vez de usar ACEs com acesso negado, use ACEs com permissão de acesso para permitir explicitamente os direitos de acesso permitidos.

Outro meio de gerenciar o acesso a objetos de armazenamento é a criptografia. A implementação da criptografia do sistema de arquivos em Windows é o Sistema de Arquivos Criptografados ou EFS. O EFS criptografa apenas arquivos e não diretórios. A vantagem da criptografia é que ela fornece proteção adicional aos arquivos aplicados na mídia e não por meio do sistema de arquivos e da arquitetura de controle de acesso padrão Windows. Para obter mais informações sobre criptografia de arquivo, consulte a Criptografia de Arquivo.

Na maioria dos casos, a capacidade de ler e gravar as configurações de segurança de um arquivo ou objeto de diretório é restrita a processos no modo kernel. Claramente, você não gostaria que nenhum processo de usuário pudesse alterar a propriedade ou a restrição de acesso em seu arquivo ou diretório privado. No entanto, um aplicativo de backup não poderá concluir seu trabalho de backup do arquivo se as restrições de acesso colocadas em seu arquivo ou diretório não permitirem que o processo de modo de usuário do aplicativo o leia. Backup aplicativos devem ser capazes de substituir as configurações de segurança de objetos de arquivo e diretório para garantir um backup completo. Da mesma forma, se um aplicativo de backup tentar gravar uma cópia de backup do arquivo na cópia residente em disco e você negar explicitamente privilégios de gravação para o processo de aplicativo de backup, a operação de restauração não poderá ser concluída. Nesse caso também, o aplicativo de backup deve ser capaz de substituir as configurações de controle de acesso do arquivo.

Os privilégios de acesso SE_BACKUP_NAME e SE_RESTORE_NAME foram criados especificamente para fornecer essa capacidade de backup de aplicativos. Se esses privilégios tiverem sido concedidos e habilitados no token de acesso do processo de aplicativo de backup, ele poderá chamar CreateFile para abrir seu arquivo ou diretório para backup, especificando o acesso padrão READ_CONTROL como o valor do parâmetro dwDesiredAccess . No entanto, para identificar o processo de chamada como um processo de backup, a chamada para CreateFile deve incluir o sinalizador FILE_FLAG_BACKUP_SEMANTICS no parâmetro dwFlagsAndAttributes . A sintaxe completa da chamada de função é a seguinte:

HANDLE hFile = CreateFile( fileName,                   // lpFileName
                           READ_CONTROL,               // dwDesiredAccess
                           0,                          // dwShareMode
                           NULL,                       // lpSecurityAttributes
                           OPEN_EXISTING,              // dwCreationDisposition
                           FILE_FLAG_BACKUP_SEMANTICS, // dwFlagsAndAttributes
                           NULL );                     // hTemplateFile

Isso permitirá que o processo do aplicativo de backup abra seu arquivo e substitua a verificação de segurança padrão. Para restaurar o arquivo, o aplicativo de backup usaria a sintaxe de chamada CreateFile a seguir ao abrir o arquivo a ser gravado.

HANDLE hFile = CreateFile( fileName,                   // lpFileName
                           WRITE_OWNER | WRITE_DAC,    // dwDesiredAccess
                           0,                          // dwShareMode
                           NULL,                       // lpSecurityAttributes
                           CREATE_ALWAYS,              // dwCreationDisposition
                           FILE_FLAG_BACKUP_SEMANTICS, // dwFlagsAndAttributes
                           NULL );                     // hTemplateFile

Há situações em que um aplicativo de backup deve ser capaz de alterar as configurações de controle de acesso de um arquivo ou diretório. Um exemplo é quando as configurações de controle de acesso da cópia residente em disco de um arquivo ou diretório são diferentes da cópia de backup. Isso aconteceria se essas configurações fossem alteradas após o backup do arquivo ou do diretório ou se ele estivesse corrompido.

O sinalizador FILE_FLAG_BACKUP_SEMANTICS especificado na chamada para CreateFile fornece ao processo de aplicativo de backup permissão para ler as configurações de controle de acesso do arquivo ou diretório. Com essa permissão, o processo do aplicativo de backup pode chamar GetKernelObjectSecurity e SetKernelObjectSecurity para ler e redefinir as configurações de controle de acesso.

Se um aplicativo de backup precisar ter acesso às configurações de controle de acesso no nível do sistema, o sinalizador ACCESS_SYSTEM_SECURITY deverá ser especificado no valor do parâmetro dwDesiredAccess passado para CreateFile.

Backup aplicativos chamam BackupRead para ler os arquivos e diretórios especificados para a operação de restauração e BackupWrite para gravá-los.

Tópicos relacionados

direitos de acesso padrão