Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug][ResourceAccessControl] AccessDenied when checking existence of a resource that is not defined in the same module #12623

Open
rahxephon89 opened this issue Mar 21, 2024 · 0 comments
Assignees
Labels
bug Something isn't working compiler-v2 stale-exempt Prevents issues from being automatically marked and closed as stale

Comments

@rahxephon89
Copy link
Contributor

馃悰 Bug

When checking existence of a resource defined in a different module, the error "ACCESS_DENIED" will be generated. For instance, when executing the set function in the execution_config module, the error is raised in the function assert_genesis where existence of the resource GenesisEndMarker is checked :

    public fun set(account: &signer, config: vector<u8>) acquires ExecutionConfig {
        system_addresses::assert_aptos_framework(account);
        chain_status::assert_genesis();
        //...
    }

The reason is that the AccessSpecifier is

Constraint([AccessSpecifierClause { kind: Acquires, resource: Resource(StructIdentifier { module: ModuleId { address: 0000000000000000000000000000000000000000000000000000000000000001, name: Identifier("execution_config") }, name: Identifier("ExecutionConfig") }), address: Any }], [])

while the AccessInstance is:

 { kind: Reads, resource: StructIdentifier { module: ModuleId { address: 0000000000000000000000000000000000000000000000000000000000000001, name: Identifier("chain_status") }, name: Identifier("GenesisEndMarker") }, instance: [], address: 0000000000000000000000000000000000000000000000000000000000000001 }

Then the enables function checks that the resource does not match, leading to the error.

@rahxephon89 rahxephon89 added bug Something isn't working compiler-v2 labels Mar 21, 2024
@sausagee sausagee added the stale-exempt Prevents issues from being automatically marked and closed as stale label Mar 21, 2024
wrwg added a commit that referenced this issue Apr 3, 2024
This introduces the concept of a language version and pipes it through the various layers of the stack, from aptos CLI down to compiler v2, prover, and transactional test framework.

- The `LanguageVersion` resides in the new file in the Move model, `metadata.rs`. The `CompilerVersion` has been also moved from the package system into there.  Compiler and language version support formatting and parsing. They also support their default being populated from env vars `MOVE_COMPILER_V2` and `MOVE_LANGUAGE_V2`, respectively.
- There is also a new data structure `CompilationMetadata` which we can use to attach to the file format metadata section in subsequent PRs.
- Both compiler and language version have a qualifier whether a particular version is 'stable'. The value of this is populated in `CompilationMetadata` so we can perform run time checks and disallow an unstable version on production chains (subsequent PRs).
- The aptos cli will print out a warning if an unstable compiler or language version is used.
- The language version is attached to the GlobalEnv. The expression builder will refuse to build language constructs not supported by a given language version.
- File format generator will not generate access specifiers if language v2 is not selected or if a special new experiment GEN_ACCESS_SPECIFIERS is on. This mitigates #12623 for now so we can lower priority but does not close it.
- The acquires checks have been adapted to use the language version in the exp_builder instead of the previous flag.
- A new test directory `checking-lang-v1` has been created to contain tests checking for disallowed v2 language features; some acquires related tests have been move there as well.
wrwg added a commit that referenced this issue Apr 4, 2024
This introduces the concept of a language version and pipes it through the various layers of the stack, from aptos CLI down to compiler v2, prover, and transactional test framework.

- The `LanguageVersion` resides in the new file in the Move model, `metadata.rs`. The `CompilerVersion` has been also moved from the package system into there.  Compiler and language version support formatting and parsing. They also support their default being populated from env vars `MOVE_COMPILER_V2` and `MOVE_LANGUAGE_V2`, respectively.
- There is also a new data structure `CompilationMetadata` which we can use to attach to the file format metadata section in subsequent PRs.
- Both compiler and language version have a qualifier whether a particular version is 'stable'. The value of this is populated in `CompilationMetadata` so we can perform run time checks and disallow an unstable version on production chains (subsequent PRs).
- The aptos cli will print out a warning if an unstable compiler or language version is used.
- The language version is attached to the GlobalEnv. The expression builder will refuse to build language constructs not supported by a given language version.
- File format generator will not generate access specifiers if language v2 is not selected or if a special new experiment GEN_ACCESS_SPECIFIERS is on. This mitigates #12623 for now so we can lower priority but does not close it.
- The acquires checks have been adapted to use the language version in the exp_builder instead of the previous flag.
- A new test directory `checking-lang-v1` has been created to contain tests checking for disallowed v2 language features; some acquires related tests have been move there as well.
wrwg added a commit that referenced this issue Apr 4, 2024
* [compiler-v2] Introduce language version

This introduces the concept of a language version and pipes it through the various layers of the stack, from aptos CLI down to compiler v2, prover, and transactional test framework.

- The `LanguageVersion` resides in the new file in the Move model, `metadata.rs`. The `CompilerVersion` has been also moved from the package system into there.  Compiler and language version support formatting and parsing. They also support their default being populated from env vars `MOVE_COMPILER_V2` and `MOVE_LANGUAGE_V2`, respectively.
- There is also a new data structure `CompilationMetadata` which we can use to attach to the file format metadata section in subsequent PRs.
- Both compiler and language version have a qualifier whether a particular version is 'stable'. The value of this is populated in `CompilationMetadata` so we can perform run time checks and disallow an unstable version on production chains (subsequent PRs).
- The aptos cli will print out a warning if an unstable compiler or language version is used.
- The language version is attached to the GlobalEnv. The expression builder will refuse to build language constructs not supported by a given language version.
- File format generator will not generate access specifiers if language v2 is not selected or if a special new experiment GEN_ACCESS_SPECIFIERS is on. This mitigates #12623 for now so we can lower priority but does not close it.
- The acquires checks have been adapted to use the language version in the exp_builder instead of the previous flag.
- A new test directory `checking-lang-v1` has been created to contain tests checking for disallowed v2 language features; some acquires related tests have been move there as well.

* Addressing reviewer comments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working compiler-v2 stale-exempt Prevents issues from being automatically marked and closed as stale
Projects
Status: Assigned
Development

No branches or pull requests

3 participants