Skip to content

Grant runtime access to Lua functions via configuration #4552

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.

Sign up for GitHub

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

Already on GitHub? Sign in to your account

Jump to bottom
Open
Tracked by #4505
TarantoolBot opened this issue Sep 25, 2024 · 2 comments
Open
Tracked by #4505

Grant runtime access to Lua functions via configuration #4552

TarantoolBot opened this issue Sep 25, 2024 · 2 comments
Assignees
@AArdeev
Labels
3.3 access Related with the granting of rights, the access config

Comments

@TarantoolBot
Copy link
Collaborator

TarantoolBot commented Sep 25, 2024 •
edited by georgiy-belyanin
Loading

Product: Tarantool
Since: 3.3
Root document:

SME: @ mandesero @ Totktonada

Details

To be done together with #4462.

It is now possible to grant execution privileges for Lua functions
through the declarative configuration, even when the database is in
read-only mode or has an outdated schema version. You might also
permit guest to execute Lua functions before the initial bootstrap.

You can specify function permissions using the lua_call option in
the configuration, for example:

credentials:
  users:
    alice:
      privileges:
        - permissions: [execute]
          lua_call: [my_func]

This grants the alice user permission to execute the my_func Lua
function, regardless of the database's mode or status. The special option
lua_call: [all] is also supported, granting access to all global Lua
functions except built-in ones, bypassing database restrictions.

Privileges will still be written to the database when possible to
maintain compatibility and consistency with other privilege types.
Requested by @mandesero in tarantool/tarantool@38c6b0d.
@Totktonada Totktonada mentioned this issue Sep 25, 2024
Closed
@p7nov p7nov added 3.2 config access Related with the granting of rights, the access labels Sep 27, 2024
@p7nov p7nov mentioned this issue Sep 27, 2024
Closed
17 tasks
@p7nov p7nov self-assigned this Nov 21, 2024
@Totktonada
Copy link
Member

NB: Changed 'since 3.2' to 'since 3.3'. See tarantool/tarantool#10310.

@p7nov p7nov added 3.3 and removed 3.2 labels Nov 21, 2024
@georgiy-belyanin
Copy link
Member

NB: changed

It is now possible to grant execution privileges for Lua functions
through the declarative configuration, even when the database is in
read-only mode or has an outdated schema version.

-> 

It is now possible to grant execution privileges for Lua functions
through the declarative configuration, even when the database is in
read-only mode or has an outdated schema version. You might also
permit `guest` to execute Lua functions before the initial bootstrap.

georgiy-belyanin added a commit to georgiy-belyanin/tarantool that referenced this issue Mar 25, 2025
@georgiy-belyanin
config: apply lua_call privileges before bootstrap
ad099ec 
This patch is a bugfix of the `lua_call` runtime access implemented in
commit 38c6b0d ("config: grant runtime access to lua_call from
config").

One of the main reason for runtime privileges is to allow granting guest
user `lua_call` access before the initial bootstrap. During the
implementation of the tarantool#10857 in terms of the new behavior of the
supervised failover with the supervised bootstrap strategy it turned out
runtime privileges haven't been added as a first-phase applier making it
impossible to executing some of the lua functions before the initial
bootstrap. This patch fixes it by adding a first-phase applier.

For instance, you might allow guest connection to fetch information on
instances before the bootstrap by configuring `credentials` section like
this.

```yaml
credentials:
  guest:
    privileges:
    - permissions: [ execute ]
      lua_call: [box.info]
```

NO_DOC=see tarantool/doc#4552, added a comment on it
@georgiy-belyanin georgiy-belyanin mentioned this issue Mar 25, 2025
Merged
georgiy-belyanin added a commit to georgiy-belyanin/tarantool that referenced this issue Mar 25, 2025
@georgiy-belyanin
config: apply lua_call privileges before bootstrap
79e4582 
This patch is a bugfix of the `lua_call` runtime access implemented in
commit 38c6b0d ("config: grant runtime access to lua_call from
config").

One of the main reason for runtime privileges is to allow granting guest
user `lua_call` access before the initial bootstrap. During the
implementation of the tarantool#10857 in terms of the new behavior of the
supervised failover with the supervised bootstrap strategy it turned out
runtime privileges haven't been added as a first-phase applier making it
impossible to executing some of the lua functions before the initial
bootstrap. This patch fixes it by adding a first-phase applier.

For instance, you might allow guest connection to fetch information on
instances before the bootstrap by configuring `credentials` section like
this.

```yaml
credentials:
  guest:
    privileges:
    - permissions: [ execute ]
      lua_call: [box.info]
```

NO_DOC=see tarantool/doc#4552, added a comment on it
georgiy-belyanin added a commit to georgiy-belyanin/tarantool that referenced this issue Mar 25, 2025
@georgiy-belyanin
config: apply lua_call privileges before bootstrap
fff19cb 
This patch is a bugfix of the `lua_call` runtime access implemented in
commit 38c6b0d ("config: grant runtime access to lua_call from
config").

One of the main reason for runtime privileges is to allow granting guest
user `lua_call` access before the initial bootstrap. During the
implementation of the tarantool#10857 in terms of the new behavior of the
supervised failover with the supervised bootstrap strategy it turned out
runtime privileges haven't been added as a first-phase applier making it
impossible to executing some of the lua functions before the initial
bootstrap. This patch fixes it by adding a first-phase applier.

For instance, you might allow guest connection to fetch information on
instances before the bootstrap by configuring `credentials` section like
this.

```yaml
credentials:
  guest:
    privileges:
    - permissions: [ execute ]
      lua_call: [box.info]
```

NO_DOC=see tarantool/doc#4552, added a comment on it
Totktonada pushed a commit to tarantool/tarantool that referenced this issue Mar 25, 2025
@georgiy-belyanin @Totktonada
config: apply lua_call privileges before bootstrap
f001417 
This patch is a bugfix of the `lua_call` runtime access implemented in
commit 38c6b0d ("config: grant runtime access to lua_call from
config").

One of the main reason for runtime privileges is to allow granting guest
user `lua_call` access before the initial bootstrap. During the
implementation of the #10857 in terms of the new behavior of the
supervised failover with the supervised bootstrap strategy it turned out
runtime privileges haven't been added as a first-phase applier making it
impossible to executing some of the lua functions before the initial
bootstrap. This patch fixes it by adding a first-phase applier.

For instance, you might allow guest connection to fetch information on
instances before the bootstrap by configuring `credentials` section like
this.

```yaml
credentials:
  guest:
    privileges:
    - permissions: [ execute ]
      lua_call: [box.info]
```

NO_DOC=see tarantool/doc#4552, added a comment on it
github-actions bot pushed a commit to tarantool/tarantool that referenced this issue Mar 25, 2025
@georgiy-belyanin @github-actions
config: apply lua_call privileges before bootstrap
78f488b 
This patch is a bugfix of the `lua_call` runtime access implemented in
commit 38c6b0d ("config: grant runtime access to lua_call from
config").

One of the main reason for runtime privileges is to allow granting guest
user `lua_call` access before the initial bootstrap. During the
implementation of the #10857 in terms of the new behavior of the
supervised failover with the supervised bootstrap strategy it turned out
runtime privileges haven't been added as a first-phase applier making it
impossible to executing some of the lua functions before the initial
bootstrap. This patch fixes it by adding a first-phase applier.

For instance, you might allow guest connection to fetch information on
instances before the bootstrap by configuring `credentials` section like
this.

```yaml
credentials:
  guest:
    privileges:
    - permissions: [ execute ]
      lua_call: [box.info]
```

NO_DOC=see tarantool/doc#4552, added a comment on it

(cherry picked from commit f001417)
@TarantoolBot TarantoolBot mentioned this issue Mar 25, 2025
Merged
Totktonada pushed a commit to tarantool/tarantool that referenced this issue Mar 25, 2025
@georgiy-belyanin @Totktonada
config: apply lua_call privileges before bootstrap
d889b7d 
This patch is a bugfix of the `lua_call` runtime access implemented in
commit 38c6b0d ("config: grant runtime access to lua_call from
config").

One of the main reason for runtime privileges is to allow granting guest
user `lua_call` access before the initial bootstrap. During the
implementation of the #10857 in terms of the new behavior of the
supervised failover with the supervised bootstrap strategy it turned out
runtime privileges haven't been added as a first-phase applier making it
impossible to executing some of the lua functions before the initial
bootstrap. This patch fixes it by adding a first-phase applier.

For instance, you might allow guest connection to fetch information on
instances before the bootstrap by configuring `credentials` section like
this.

```yaml
credentials:
  guest:
    privileges:
    - permissions: [ execute ]
      lua_call: [box.info]
```

NO_DOC=see tarantool/doc#4552, added a comment on it

(cherry picked from commit f001417)
@AArdeev AArdeev self-assigned this May 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@AArdeev AArdeev

Labels
3.3 access Related with the granting of rights, the access config
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@Totktonada @georgiy-belyanin @TarantoolBot @p7nov @AArdeev