Início / coding / Perguntas / 79590793
Accepted
JFFIGK
Asked: 2025-04-24 22:05:40 +0800 CST

Por que definir um valor em uma chave de registro aberta (em vez de criada) gera "Acesso negado"?

  • 772

Abra uma chave de registro para gravar usando create:

pub fn main() -> Result<(), windows::core::Error> {
    let auto_start = windows_registry::CURRENT_USER.create("SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run")?;
    auto_start.set_value("Test", &windows_registry::Value::from("content"))?;
    Ok(())
}

Isso funciona como esperado (create apenas abre a chave como ela já existe, e o valor é adicionado).

Entretanto, como a chave já existe, eu gostaria de simplesmente abri-la, por exemplo, como o seguinte:

fn main() -> Result<(), windows::core::Error> {
    let auto_start = windows_registry::CURRENT_USER.open("SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run")?;
    auto_start.set_value("Test", &windows_registry::Value::from("content"))?;
    Ok(())
}

No entanto, ele falha com um erro de acesso negado, mesmo se eu executar o programa em um terminal iniciado com "Executar como administrador":

Erro: Erro { código: HRESULT(0x80070005), mensagem: "Acesso negado." }

Por que isso acontece?

Não deveria openprecisar no máximo das mesmas permissões que create?

E por que isso nem funciona em um terminal elevado?

Curiosamente, basta abrir sem definir um valor...

rust

1 respostas

  1. Best Answer

    As funções Key::open()e Key::create()são otimizadas para ergonomia. Elas abrangem os dois padrões de acesso mais comuns:

    • open()uma chave para ler seus valores
    • create()uma chave para armazenar valores

    O acesso solicitado é codificado como KEY_READe KEY_READ | KEY_WRITE, respectivamente. Se você open()digitar - em uma chave e, em seguida, tentar escrever um valor, a chamada falhará. É assim que o sistema e a caixa foram projetados para funcionar.

    Se precisar de uma chave para escrever, você terá que solicitar KEY_WRITEpermissões. A maneira mais simples de obtê-la é chamando create()no lugar de open(). Observe a documentação :

    Cria uma chave de registro. Se a chave já existir, a função a abre.

    Notavelmente, ele abre uma chave existente para KEY_READ | KEY_WRITEacesso.

    Se precisar de mais controle, você obterá um OpenOptionsfrom 1 . O código a seguir abre explicitamente uma chave para acesso de leitura/gravação:Key::options()

    pub fn main() -> Result<(), windows::core::Error> {
    let auto_start = windows_registry::CURRENT_USER
        .options()
        .read()
        .write()
        .open("SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run")?;
    // ...
}

    Isso tem comportamento idêntico, Key::create()exceto que falha se a chave ainda não existir.

    Vamos abordar as questões restantes:

    Não deveria openprecisar no máximo das mesmas permissões que create?

    opennão precisa de nenhuma permissão. Isso é um requisito do seu programa, não da API. Se precisar de certas permissões, agora você sabe como solicitá-las.

    E por que isso nem funciona em um terminal elevado?

    Ao solicitar permissões de leitura, qualquer outro acesso é rejeitado. Não faz diferença se uma solicitação de mais permissões teria sido bem-sucedida. A única coisa que muda ao alternar para um prompt de comando elevado é que o código que solicita acesso de gravação ao LOCAL_MACHINEhive, por exemplo, é bem-sucedido quando falha em uma conta de usuário comum.

    Curiosamente, basta abrir sem definir um valor...

    Sim, claro. É assim que o sistema foi projetado. Você também pode ler essa chave. E você pode abrir uma chave sem ter permissão de leitura, tudo bem, se não solicitar nenhuma.

    1 Isso foi introduzido na versão 0.5.0; aqui está o PR que explica as escolhas de design.

    • 2

relate perguntas