Pergunta

Neste código, eu gostaria que o método ReadFileSystem a ser proibido de Assert uma permissão no sistema de arquivos.

Eu esperava isso vai atirar em fileIo.Assert (), mas isso não acontece. Por quê?

using System.Security.Permissions;
static void Main(string[] args)
{
    var fileIo = new FileIOPermission(PermissionState.Unrestricted);
    var secuPerm = new SecurityPermission(SecurityPermissionFlag.Assertion);
    PermissionSet set = new PermissionSet(PermissionState.Unrestricted);
    set.AddPermission(fileIo);
    set.AddPermission(secuPerm);
    set.Deny();
    ReadFileSystem();
    Console.Read();
}

private static void ReadFileSystem()
{
    var fileIo = newFileIOPermission(PermissionState.Unrestricted);
    fileIo.Assert();

    DirectoryInfo dir = new DirectoryInfo("C:/");
    dir.GetDirectories();
}

Atualização

Great link aqui no CAS: http: // blogs .msdn.com / shawnfa / Arquivo / 2004/08/25 / 220458.aspx

Foi útil?

Solução

A Assert posterior anula os efeitos da Negar.

A capacidade de assert FileIOPermission depende, principalmente, se a sua montagem é confiável. Ela não é afetada por um anterior Negar de FileIOPermission. Acontece que ele também não é afetado pelo anterior Negar da afirmação SecurityPermission. Isto é porque SecurityPermissionFlag.Assertion está marcada como uma demanda tempo de ligação Este não é claramente documentada.; Achei aqui .

Para forçar o CLR para não confiar em sua montagem para FileIOPermission, você pode usar o seguinte na parte superior do seu arquivo seguindo as instruções que utilizam. Quando você adicionar isso ao seu arquivo, o assert não terá efeito. Isso afeta toda a montagem. Não há maior granularidade.

[assembly:FileIOPermission(SecurityAction.RequestRefuse, Unrestricted=true)]

Outras dicas

Eu acho que você pode entender mal o propósito de permissões afirmar. Quando você Assert um conjunto de permissões na CAS, você está dizendo efetivamente "Eu sei o que estou fazendo ... Eu não ligo para o que as permissões são mais profundas na pilha." Isso é quase não o que você quer. Você geralmente quer exigem um conjunto de permissões. Isso provoca uma movimentação de pilha, o que iria encontrar o Negar na pilha e, em seguida, fazer com que uma exceção de segurança.

No entanto, desde NET tem praticamente todas as exigências necessárias embutidos, raramente há uma necessidade de realmente exigir nada menos que você está fazendo Afirma (novamente, isso é raro) ou você escreveu sua própria classe de permissão personalizada.

Boa pergunta com certeza. Eu corri o código e estou um pouco mistificada também. Eu apenas passar uma hora ou 2 estudar os documentos e pesquisando, mas sem sucesso. Note-se que MSDN policiais fora, fazendo uma demanda sobre a permissão afirmação.

Edit: A resposta de binarycoder apontou-me na direção certa .

Os direitos Asserion são simplesmente não é eficaz em um Full-empuxo montagem. Só se você adicionar o seguinte na parte superior do arquivo:

[assembly: SecurityPermissionAttribute(SecurityAction.RequestRefuse, Assertion = true)] 

a chamada para fileIo.Assert () irá falhar.

Mas por outro lado, tentando negar () a permissão afirmação e o seguinte atributo são totalmente ineficazes (a menos que você exige de forma explícita () os direitos de asserção).

[SecurityPermissionAttribute(SecurityAction.Deny, Assertion = true)]
private static void ReadFileSystem() {}

A documentação faz afirmar que Assert () 'tem alguns problemas de segurança' e a recomendação é sempre procura-before-Assert:

fileIo.Demand();
fileIo.Assert();

mas eu ainda tenho que re-ajustar a minha mentalidade sobre a aplicação do princípio do menor privilégio.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top