config: delayed privilege grant/revoke doesn't clear an alert #9574

Totktonada · 2023-12-28T23:52:07Z

Let's consider the following simple config.

credentials:
  users:
    guest:
      roles: [super]
      privileges:
      - permissions: [read, write]
        spaces: [s]

iproto:
  listen:
  - uri: 'unix/:./var/run/{{ instance_name }}/tarantool.iproto'

app:
  file: app.lua

groups:
  group-001:
    replicasets:
      replicaset-001:
        instances:
          instance-001: {}

And run it with the following application (app.lua).

box.once('app', function()
    box.schema.space.create('s')
    box.space.s:create_index('pk')
end)

Next, start the instance.

./src/tarantool --name instance-001 --config config.yaml

And connect to the admin console.

tt connect ./var/run/instance-001/tarantool.control

Check the space and the privileges.

# ./var/run/instance-001/tarantool.control> box.schema.user.info('guest')
---
- - - execute
    - role
    - public
  - - execute
    - role
    - super
  - - read,write
    - space
    - s
  - - session,usage
    - universe
    - 
...

read, write on space s is granted, everything is OK.

But,

# ./var/run/instance-001/tarantool.control> require('config'):info()
---
- status: check_warnings
  meta: []
  alerts:
  - type: warn
    message: 'credentials.apply: space "s" hasn''t been created yet, ''box.schema.user.grant("guest",
      "read,write", "space", "s")'' will be applied later'
    timestamp: 2023-12-29T02:44:11.898258+0300
...

The text was updated successfully, but these errors were encountered:

It encapsulates all the alerts manipulation in one place, splits it from the main config logic and simplifies reading of the relevant code. Several tests are updated to use the public API instead of the internal one. Part of tarantool#9574 Part of tarantool#9586 NO_DOC=refactoring, no user-visible changes NO_CHANGELOG=see NO_DOC NO_TEST=see NO_DOC

The declarative configuration has the `credentials` section that describes users and their privileges. It is OK to have privileges for a space/function/sequence that is not exists. Such a privilege will lead to an alert that states that the privilege will be granted, when the object will be created. The problem that is fixed by this commit is that such an alert was not dropped, when the object is created and the relevant privileges are granted. Updated several unit test cases, because the credentials applier now depends more on the `config` module: successful privilege grant calls `config._aboard:drop()`. Fixes tarantool#9574 NO_DOC=bugfix

It encapsulates all the alerts manipulation in one place, splits it from the main config logic and simplifies reading of the relevant code. Several tests are updated to use the public API instead of the internal one. Part of tarantool#9574 Part of tarantool#9586 NO_DOC=refactoring, no user-visible changes NO_CHANGELOG=see NO_DOC NO_TEST=see NO_DOC

The declarative configuration has the `credentials` section that describes users and their privileges. It is OK to have privileges for a space/function/sequence that does not exist. Such a privilege will lead to an alert that states that the privilege will be granted, when the object will be created. The problem that is fixed by this commit is that such an alert was not dropped, when the object is created and the relevant privileges are granted. Updated several unit test cases, because the credentials applier now depends more on the `config` module: successful privilege grant calls `config._aboard:drop()`. Fixes tarantool#9574 NO_DOC=bugfix

It encapsulates all the alerts manipulation in one place, splits it from the main config logic and simplifies reading of the relevant code. Several tests are updated to use the public API instead of the internal one. Part of tarantool#9574 Part of tarantool#9586 NO_DOC=refactoring, no user-visible changes NO_CHANGELOG=see NO_DOC NO_TEST=see NO_DOC

The declarative configuration has the `credentials` section that describes users and their privileges. It is OK to have privileges for a space/function/sequence that does not exist. Such a privilege will lead to an alert that states that the privilege will be granted, when the object will be created. The problem that is fixed by this commit is that such an alert was not dropped, when the object is created and the relevant privileges are granted. Updated several unit test cases, because the credentials applier now depends more on the `config` module: successful privilege grant calls `config._aboard:drop()`. Fixes tarantool#9574 NO_DOC=bugfix

It encapsulates all the alerts manipulation in one place, splits it from the main config logic and simplifies reading of the relevant code. Several tests are updated to use the public API instead of the internal one. Part of tarantool#9574 Part of tarantool#9586 NO_DOC=refactoring, no user-visible changes NO_CHANGELOG=see NO_DOC NO_TEST=see NO_DOC

The declarative configuration has the `credentials` section, which allows to assign privileges to access particular objects (spaces, functions, sequences) to users or roles. A privilege may be declared in the configuration before the object is created. It is OK, but an alert is issued in the case (shown via `config:info().alerts`). There is a specific case of the privileges synchronization: when an object is renamed. In this case, privileges that are set according to the old object name should be revoked and privileges that are declared for the new object name should be granted. The important point is that after the rename we have no object with the old name. If the declarative configuration has privileges declared for the old object name, we should issue alerts that they're waiting for the object appearance. It was not performed before this commit. NO_DOC=It is a fix of a bug. NO_TEST=It is cumbersome to test it in presence of tarantool#9574, which is fixed in next commit. The testing scenarios for tarantool#9574 will cover this problem as well.

The declarative configuration has the `credentials` section that describes users and their privileges. It is OK to have privileges for a space/function/sequence that does not exist. Such a privilege will lead to an alert that states that the privilege will be granted, when the object will be created. The problem that is fixed by this commit is that such an alert was not dropped, when the object is created and the relevant privileges are granted. There are several ways to solve the problem. Let's look on them. 1. When a privilege is granted, drop an alert if any. 2. After privileges synchronization, revisit alerts to drop all obsolete ones. The first way is the simplest, but it doesn't cover one specific scenario. Let's assume that the object T has privileges declared in the configuration and the object doesn't exist. There is an alert regarding it. Now, object S is renamed to T. Let's assume that S had some or all the privileges needed for T according to the configuration. In the given scenario, we don't need to grant some or all of the privileges and, so, the first solution doesn't work. We don't reach the code that grants the privileges and, so, dropping alerts on this point has no effect. Let's look on the second solution deeper. It needs traverse over alerts and analyze them. It leads to two changes in the `aboard` internal module. 1. The `aboard` module now ignores underscored fields of an alert to allow a caller to store a machine-readable information in them. 2. The new method `:pairs()` is added to allow a traverse over the alerts. This patch also changes how alerts regarding privileges for non-existing object are issued. Now, each needed permission is reported in its own alert. It is needed to simplify code that finds and drops the alerts. At least, it eliminates a need to modify an alert with regeneration of its message. Several unit test cases are updated, because the credentials applier now depends more on the `config` module: we need to access the alert board (`config._aboard`) not only when some object with declared privileges doesn't exist. Fixes tarantool#9574 NO_DOC=bugfix

It encapsulates all the alerts manipulation in one place, splits it from the main config logic and simplifies reading of the relevant code. Several tests are updated to use the public API instead of the internal one. Part of tarantool#9574 Part of tarantool#9586 NO_DOC=refactoring, no user-visible changes NO_CHANGELOG=see NO_DOC NO_TEST=see NO_DOC

The declarative configuration has the `credentials` section, which allows to assign privileges to access particular objects (spaces, functions, sequences) to users or roles. A privilege may be declared in the configuration before the object is created. It is OK, but an alert is issued in the case (shown via `config:info().alerts`). There is a specific case of the privileges synchronization: when an object is renamed. In this case, privileges that are set according to the old object name should be revoked and privileges that are declared for the new object name should be granted. The important point is that after the rename we have no object with the old name. If the declarative configuration has privileges declared for the old object name, we should issue alerts that they're waiting for the object appearance. It was not performed before this commit. NO_DOC=It is a fix of a bug. NO_TEST=It is cumbersome to test it in presence of tarantool#9574, which is fixed in next commit. The testing scenarios for tarantool#9574 will cover this problem as well.

The declarative configuration has the `credentials` section that describes users and their privileges. It is OK to have privileges for a space/function/sequence that does not exist. Such a privilege will lead to an alert that states that the privilege will be granted, when the object will be created. The problem that is fixed by this commit is that such an alert was not dropped, when the object is created and the relevant privileges are granted. There are several ways to solve the problem. Let's look on them. 1. When a privilege is granted, drop an alert if any. 2. After privileges synchronization, revisit alerts to drop all obsolete ones. The first way is the simplest, but it doesn't cover one specific scenario. Let's assume that the object T has privileges declared in the configuration and the object doesn't exist. There is an alert regarding it. Now, object S is renamed to T. Let's assume that S had some or all the privileges needed for T according to the configuration. In the given scenario, we don't need to grant some or all of the privileges and, so, the first solution doesn't work. We don't reach the code that grants the privileges and, so, dropping alerts on this point has no effect. Let's look on the second solution deeper. It needs traverse over alerts and analyze them. It leads to two changes in the `aboard` internal module. 1. The `aboard` module now ignores underscored fields of an alert on its serialization to allow a caller to store a machine-readable information in them. 2. The new method `:pairs()` is added to allow a traverse over the alerts. This patch also changes how alerts regarding privileges for non-existing object are issued. Now, each needed permission is reported in its own alert. It is needed to simplify code that finds and drops the alerts. At least, it eliminates a need to modify an alert with regeneration of its message. Several unit test cases are updated, because the credentials applier now depends more on the `config` module: we need to access the alert board (`config._aboard`) not only when some object with declared privileges doesn't exist. Fixes tarantool#9574 NO_DOC=bugfix

It encapsulates all the alerts manipulation in one place, splits it from the main config logic and simplifies reading of the relevant code. Several tests are updated to use the public API instead of the internal one. Part of tarantool#9574 Part of tarantool#9586 NO_DOC=refactoring, no user-visible changes NO_CHANGELOG=see NO_DOC NO_TEST=see NO_DOC

The declarative configuration has the `credentials` section that describes users and their privileges. It is OK to have privileges for a space/function/sequence that does not exist. Such a privilege will lead to an alert that states that the privilege will be granted, when the object will be created. The problem that is fixed by this commit is that such an alert was not dropped, when the object is created and the relevant privileges are granted. There are several ways to solve the problem. Let's look on them. 1. When a privilege is granted, drop an alert if any. 2. After the config-database privilege synchronization, revisit alerts to drop all obsolete ones. 3. Drop all the alerts regarding missed privileges before the config-database privilege synchronization and issue actual alerts afterwards. The first way is the simplest, but it doesn't cover one specific scenario: an object rename. Let's assume that the object T has privileges declared in the configuration and the object doesn't exist. There is an alert regarding it. Now, object S is renamed to T. Let's assume that S had some or all the privileges needed for T according to the configuration. In the given scenario, we don't need to grant some or all of the privileges and, so, the first solution doesn't work. We don't reach the code that grants the privileges and, so, dropping alerts on this point has no effect. The second and the third solutions are similar and mainly differs in how complicated the code is. The third one is implemented here with idea of simplicity of the code in the mind. The internal `aboard` module has the following changes. 1. The `aboard` module now ignores underscored fields of an alert on its serialization to allow a caller to store a machine-readable information in them. 2. The new method `:drop_if()` is added to perform a conditional alert drop. Several unit test cases are updated, because the credentials applier now depends more on the `config` module: we need to access the alert board (`config._aboard`) not only when some object with declared privileges doesn't exist. Fixes tarantool#9574 NO_DOC=bugfix

It encapsulates all the alerts manipulation in one place, splits it from the main config logic and simplifies reading of the relevant code. Several tests are updated to use the public API instead of the internal one. Part of tarantool#9574 Part of tarantool#9586 NO_DOC=refactoring, no user-visible changes NO_CHANGELOG=see NO_DOC NO_TEST=see NO_DOC

The declarative configuration has the `credentials` section that describes users and their privileges. It is OK to have privileges for a space/function/sequence that does not exist. Such a privilege will lead to an alert that states that the privilege will be granted, when the object is created. The problem that is fixed by this commit is that such an alert was not dropped, when the object is created and the relevant privileges are granted. There are several ways to solve the problem. Let's look on them. 1. When a privilege is granted, drop an alert if any. 2. After the config-database privilege synchronization, revisit alerts to drop all obsolete ones. 3. Drop all the alerts regarding missed privileges before the config-database privilege synchronization and issue actual alerts afterwards. The first way is the simplest, but it doesn't cover one specific scenario: an object rename. Let's assume that the object T has privileges declared in the configuration and the object doesn't exist. There is an alert regarding it. Now, object S is renamed to T. Let's assume that S had some or all the privileges needed for T according to the configuration. In the given scenario, we don't need to grant some or all of the privileges and, so, the first solution doesn't work. We don't reach the code that grants the privileges and, so, dropping alerts at this point has no effect. The second and the third solutions are similar and mainly differs in how complicated the code is. The third one is implemented here with idea of simplifying of the code. The internal `aboard` module has the following changes. 1. The `aboard` module now ignores underscored fields of an alert on its serialization to allow a caller to store a machine-readable information in them. 2. The new method `:drop_if()` is added to perform a conditional alert drop. Several unit test cases are updated, because the credentials applier now depends more on the `config` module: we need to access the alert board (`config._aboard`) not only when some object with declared privileges doesn't exist. Fixes tarantool#9574 NO_DOC=bugfix

The declarative configuration has the `credentials` section that describes users and their privileges. It is OK to have privileges for a space/function/sequence that does not exist. Such a privilege will lead to an alert that states that the privilege will be granted, when the object is created. The problem that is fixed by this commit is that such an alert was not dropped, when the object is created and the relevant privileges are granted. There are several ways to solve the problem. Let's look on them. 1. When a privilege is granted, drop an alert if any. 2. After the config-database privilege synchronization, revisit alerts to drop all obsolete ones. 3. Drop all the alerts regarding missed privileges before the config-database privilege synchronization and issue actual alerts afterwards. The first way is the simplest, but it doesn't cover one specific scenario: an object rename. Let's assume that the object T has privileges declared in the configuration and the object doesn't exist. There is an alert regarding it. Now, object S is renamed to T. Let's assume that S had some or all the privileges needed for T according to the configuration. In the given scenario, we don't need to grant some or all of the privileges and, so, the first solution doesn't work. We don't reach the code that grants the privileges and, so, dropping alerts at this point has no effect. The second and the third solutions are similar and mainly differs in how complicated the code is. The third one is implemented here with idea of simplifying of the code. The internal `aboard` module has the following changes. 1. The `aboard` module now ignores underscored fields of an alert on its serialization to allow a caller to store a machine-readable information in them. 2. The new method `:drop_if()` is added to perform a conditional alert drop. Several unit test cases are updated, because now we always need initialized `config._aboard` for testing of the credentials applier. Fixes tarantool#9574 NO_DOC=bugfix

The declarative configuration has the `credentials` section that describes users and their privileges. It is OK to have privileges for a space/function/sequence that does not exist. Such a privilege will lead to an alert that states that the privilege will be granted, when the object is created. The problem that is fixed by this commit is that such an alert was not dropped, when the object is created and the relevant privileges are granted. There are several ways to solve the problem. Let's look on them. 1. When a privilege is granted, drop an alert if any. 2. After the config-database privilege synchronization, revisit alerts to drop all obsolete ones. 3. Drop all the alerts regarding missed privileges before the config-database privilege synchronization and issue actual alerts afterwards. The first way is the simplest, but it doesn't cover one specific scenario: an object rename. Let's assume that the object T has privileges declared in the configuration and the object doesn't exist. There is an alert regarding it. Now, object S is renamed to T. Let's assume that S had some or all the privileges needed for T according to the configuration. In the given scenario, we don't need to grant some or all of the privileges and, so, the first solution doesn't work. We don't reach the code that grants the privileges and, so, dropping alerts at this point has no effect. The second and the third solutions are similar and mainly differs in how complicated the code is. The third one is implemented here with idea of simplifying the code. The internal `aboard` module has the following changes. 1. The `aboard` module now ignores underscored fields of an alert on its serialization to allow a caller to store a machine-readable information in them. 2. The new method `:drop_if()` is added to perform a conditional alert drop. Several unit test cases are updated, because now we always need initialized `config._aboard` for testing of the credentials applier. Fixes tarantool#9574 NO_DOC=bugfix

It encapsulates all the alerts manipulation in one place, splits it from the main config logic and simplifies reading of the relevant code. Several tests are updated to use the public API instead of the internal one. Part of #9574 Part of #9586 NO_DOC=refactoring, no user-visible changes NO_CHANGELOG=see NO_DOC NO_TEST=see NO_DOC

The declarative configuration has the `credentials` section that describes users and their privileges. It is OK to have privileges for a space/function/sequence that does not exist. Such a privilege will lead to an alert that states that the privilege will be granted, when the object is created. The problem that is fixed by this commit is that such an alert was not dropped, when the object is created and the relevant privileges are granted. There are several ways to solve the problem. Let's look on them. 1. When a privilege is granted, drop an alert if any. 2. After the config-database privilege synchronization, revisit alerts to drop all obsolete ones. 3. Drop all the alerts regarding missed privileges before the config-database privilege synchronization and issue actual alerts afterwards. The first way is the simplest, but it doesn't cover one specific scenario: an object rename. Let's assume that the object T has privileges declared in the configuration and the object doesn't exist. There is an alert regarding it. Now, object S is renamed to T. Let's assume that S had some or all the privileges needed for T according to the configuration. In the given scenario, we don't need to grant some or all of the privileges and, so, the first solution doesn't work. We don't reach the code that grants the privileges and, so, dropping alerts at this point has no effect. The second and the third solutions are similar and mainly differs in how complicated the code is. The third one is implemented here with idea of simplifying the code. The internal `aboard` module has the following changes. 1. The `aboard` module now ignores underscored fields of an alert on its serialization to allow a caller to store a machine-readable information in them. 2. The new method `:drop_if()` is added to perform a conditional alert drop. Several unit test cases are updated, because now we always need initialized `config._aboard` for testing of the credentials applier. Fixes #9574 NO_DOC=bugfix

It encapsulates all the alerts manipulation in one place, splits it from the main config logic and simplifies reading of the relevant code. Several tests are updated to use the public API instead of the internal one. Part of tarantool#9574 Part of tarantool#9586 NO_DOC=refactoring, no user-visible changes NO_CHANGELOG=see NO_DOC NO_TEST=see NO_DOC (cherry picked from commit 6b84f7c)

The declarative configuration has the `credentials` section that describes users and their privileges. It is OK to have privileges for a space/function/sequence that does not exist. Such a privilege will lead to an alert that states that the privilege will be granted, when the object is created. The problem that is fixed by this commit is that such an alert was not dropped, when the object is created and the relevant privileges are granted. There are several ways to solve the problem. Let's look on them. 1. When a privilege is granted, drop an alert if any. 2. After the config-database privilege synchronization, revisit alerts to drop all obsolete ones. 3. Drop all the alerts regarding missed privileges before the config-database privilege synchronization and issue actual alerts afterwards. The first way is the simplest, but it doesn't cover one specific scenario: an object rename. Let's assume that the object T has privileges declared in the configuration and the object doesn't exist. There is an alert regarding it. Now, object S is renamed to T. Let's assume that S had some or all the privileges needed for T according to the configuration. In the given scenario, we don't need to grant some or all of the privileges and, so, the first solution doesn't work. We don't reach the code that grants the privileges and, so, dropping alerts at this point has no effect. The second and the third solutions are similar and mainly differs in how complicated the code is. The third one is implemented here with idea of simplifying the code. The internal `aboard` module has the following changes. 1. The `aboard` module now ignores underscored fields of an alert on its serialization to allow a caller to store a machine-readable information in them. 2. The new method `:drop_if()` is added to perform a conditional alert drop. Several unit test cases are updated, because now we always need initialized `config._aboard` for testing of the credentials applier. Fixes tarantool#9574 NO_DOC=bugfix (cherry picked from commit 1c1ee4d)

It encapsulates all the alerts manipulation in one place, splits it from the main config logic and simplifies reading of the relevant code. Several tests are updated to use the public API instead of the internal one. Part of #9574 Part of #9586 NO_DOC=refactoring, no user-visible changes NO_CHANGELOG=see NO_DOC NO_TEST=see NO_DOC (cherry picked from commit 6b84f7c)

The declarative configuration has the `credentials` section that describes users and their privileges. It is OK to have privileges for a space/function/sequence that does not exist. Such a privilege will lead to an alert that states that the privilege will be granted, when the object is created. The problem that is fixed by this commit is that such an alert was not dropped, when the object is created and the relevant privileges are granted. There are several ways to solve the problem. Let's look on them. 1. When a privilege is granted, drop an alert if any. 2. After the config-database privilege synchronization, revisit alerts to drop all obsolete ones. 3. Drop all the alerts regarding missed privileges before the config-database privilege synchronization and issue actual alerts afterwards. The first way is the simplest, but it doesn't cover one specific scenario: an object rename. Let's assume that the object T has privileges declared in the configuration and the object doesn't exist. There is an alert regarding it. Now, object S is renamed to T. Let's assume that S had some or all the privileges needed for T according to the configuration. In the given scenario, we don't need to grant some or all of the privileges and, so, the first solution doesn't work. We don't reach the code that grants the privileges and, so, dropping alerts at this point has no effect. The second and the third solutions are similar and mainly differs in how complicated the code is. The third one is implemented here with idea of simplifying the code. The internal `aboard` module has the following changes. 1. The `aboard` module now ignores underscored fields of an alert on its serialization to allow a caller to store a machine-readable information in them. 2. The new method `:drop_if()` is added to perform a conditional alert drop. Several unit test cases are updated, because now we always need initialized `config._aboard` for testing of the credentials applier. Fixes #9574 NO_DOC=bugfix (cherry picked from commit 1c1ee4d)

Totktonada added bug Something isn't working 3.0 Target is 3.0 and all newer release/master branches config labels Dec 28, 2023

Totktonada self-assigned this Jan 16, 2024

Totktonada mentioned this issue Jan 16, 2024

config: fix missing and stuck alerts #9598

Merged

Totktonada closed this as completed in #9598 Feb 2, 2024

Totktonada mentioned this issue Feb 2, 2024

[backport 3.0] config: fix missing and stuck alerts #9645

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

config: delayed privilege grant/revoke doesn't clear an alert #9574

config: delayed privilege grant/revoke doesn't clear an alert #9574

Totktonada commented Dec 28, 2023

config: delayed privilege grant/revoke doesn't clear an alert #9574

config: delayed privilege grant/revoke doesn't clear an alert #9574

Comments

Totktonada commented Dec 28, 2023