Database-level access control #2309

dvkashapov · 2025-07-04T12:18:20Z

API changes and user behavior:

Default behavior for database access.

Default is alldbs permissions.

Database Permissions (`db=`)

Accessing particular database

> ACL SETUSER test1 on +@all ~* resetdbs db=0,1 nopass
"user test1 on nopass sanitize-payload ~* resetchannels db=0,1 +@all"

(Same behavior without usage of resetdbs)

> ACL SETUSER test1 on +@all ~* db=0,1 nopass
"user test1 on nopass sanitize-payload ~* resetchannels db=0,1 +@all"

Multiple selector can be provided

> ACL SETUSER test1 on nopass (db=0,1 +@write +select ~*) (db=2,3 +@read +select ~*)
"user test1 on nopass sanitize-payload resetchannels alldbs -@all (~* resetchannels db=0,1 -@all +@write +select) (~* resetchannels db=2,3 -@all +@read +select)"

Restricting special commands which access databases as part of the command.

The user needs to have access to both the commands and db(s) part of the command to run these commands.

SWAPDB
SELECT
MIGRATE
MOVE - (Select command would have went through for the source database). Have access for the target database.

Restricting special commands which doesn't specify database number, however, accesses multiple databases.

The user needs to have access to both the commands and all databases (alldbs) to run these commands.

FLUSHALL - Access all databases
CLUSTER commands that access all databases:
- CANCELSLOTMIGRATIONS
- COUNTKEYSINSLOT
- GETKEYSINSLOT
- MIGRATESLOTS

New connection establishment behavior
New client connection gets established to DB 0 by default. Authentication and authorisation are decoupled and the user can connect/authenticate and further perform SELECT operation.

(Do we want to extend HELLO?) Alternative suggestion by @madolson: Extend HELLO command to pass the dbid to which the user should get connected after authentication if they have right set of permission. I think it will become a long poll for adoption.

Observability
Without ACL LOG support to flag denied permission for database, it will be difficult for user/administrator to identify malicious activity. So, I think we should extend ACL LOG to log user which received denied permission error while accessing a database.
Module API

Introduce VM_ACLCheckPermissions(ValkeyModuleUser *user, ValkeyModuleString **argv, int argc, int dbid); API
Stop support of VM_ACLCheckCommandPermissions.

Open Issues

#2309 (comment)

Resolves: #1336

dvkashapov · 2025-07-04T12:21:24Z

Hello! I would greatly appreciate any feedback from ACL experts)
@xbasel @hpatro @madolson

hwware · 2025-07-04T14:45:41Z

I would like to first discuss this new feature in the weekly meeting. Thanks

src/acl.c

src/module.c

src/multi.c

madolson · 2025-07-14T14:55:52Z

Just discussed in the weekly meeting. It seems like we are all aligned to add more database features. We don't want folks to use database instead of true multi-tenancy, like running multiple containers, but there are still plenty of workloads that could benefit from the having access control on databases for namespacing. So we'll move forward with this feature.

hpatro

Thanks for working on this @JoBeR007.

High level comment:

I would prefer us to come up with a symbol for DB, let's say ^ and use that instead of db= as prefix to have the same experience as other Then it would look like,

All database access: ACL SETUSER alice ^*
Selective database access: ACL SETUSER bob ^1 ^2

With DB I find providing both ALLOW and DENY would be helpful. Possibly extend it to other resources in a separate PR.

Restrict admin db access via (-^?):

Allow all except db 0: ACL SETUSER alice -^0

For FLUSHALL and FLUSHDB the command can get accepted as ASYNC and while it's getting executed the permission could change. I think the correct behavior is to still process the command completely even if the permission has changed at a later point. (The PR has the correct behavior).

src/acl.c

hpatro · 2025-07-31T19:55:59Z

src/acl.c

+                        if (keyidxptr) {
+                            if (cmd->proc == selectCommand)
+                                *keyidxptr = 1;
+                            else if (cmd->proc == moveCommand)
+                                *keyidxptr = 2;
+                            else if (cmd->proc == swapdbCommand)
+                                *keyidxptr = (i == 0) ? 1 : 2;
+                            else
+                                *keyidxptr = 0;
+                        }


need to handle flushdb here. This part of the code doesn't seem very readable. Let me think more and come up with something.

Agreed that this needs improvement, don't really have an idea for how to do it cleaner.

need to handle flushdb here

It is handled as a general case in last else if because FLUSHDB is related to current dbid

This part of the code doesn't seem very readable

Added todo here, still can't think of clean way to set keyidxptr

src/acl.c

dvkashapov · 2025-08-01T06:04:22Z

Thanks for review @hpatro!
I see where you're coming from in terms of one token per symbol. Do you think originally proposed syntax (db=<list> / db!=<list>) is worse than one token per symbol? For me explicit list seemed like a better idea in terms of specifying multiple selectors because it provided better readability and seemed more compact.
Also about ALLOW and DENY ACL: I suggest in this PR we add only ALLOW policies and as a separate PR I will add DENY policy for different rules and from that point we will think about usefulness of each DENY policy.

madolson · 2025-09-03T19:53:22Z

@dvkashapov Just to be transparent with you. This PR was opened at a time when we were working on the 9.0 release, and so we weren't going to merge this feature in to it. Now that the RC candidates are mostly done we can start reviewing this again for the next release. I think we'll have more time now to review it and make progress.

With DB I find providing both ALLOW and DENY would be helpful. Possibly extend it to other resources in a separate PR.

This is inconsistent with the rest of the ACL system. Today everything is positive grants. Lots of people think that if you do -get +@string, the negation of get overrules the adding of the string category. That isn't correct, as you will still have access to get. Having allows and denies for databases will just add on to that confusion. If we want to have negative policies, we should have a more generic solution. I'm fine with another issue for this though.

For FLUSHALL and FLUSHDB the command can get accepted as ASYNC and while it's getting executed the permission could change. I think the correct behavior is to still process the command completely even if the permission has changed at a later point. (The PR has the correct behavior).

From the end user perspective, the FLUSH always happens synchronously. The data is just freed async. I think this behavior is fine.

All database access: ACL SETUSER alice ^* Selective database access: ACL SETUSER bob ^1 ^2

I think this is less readable than the original proposal, but it is more consistent. I don't know how strongly I feel.

I see where you're coming from in terms of one token per symbol. Do you think originally proposed syntax (db= / db!=) is worse than one token per symbol? For me explicit list seemed like a better idea in terms of specifying multiple selectors because it provided better readability and seemed more compact.
Also about ALLOW and DENY ACL: I suggest in this PR we add only ALLOW policies and as a separate PR I will add DENY policy for different rules and from that point we will think about usefulness of each DENY policy.

- Implemented database permissions using `db=<id>`, `db!=<id>`, `alldbs`, `resetdbs` ACL rules - Added SELECTOR_FLAG_ALLDBS and SELECTOR_FLAG_DBLIST_NEGATED flags - Updated SELECT, MOVE, SWAPDB, FLUSHDB commands with CMD_CROSS_DB flag, FLUSHALL - CMD_ALL_DBS - Extended ACL checks with database access verification - Added ACL_DENIED_DB error type for database permission violations - Maintained backward compatibility with default access to all databases Signed-off-by: Daniil Kashapov <[email protected]>

Signed-off-by: Daniil Kashapov <[email protected]>

dvkashapov · 2025-10-21T12:25:26Z

@madolson @hpatro Hello! It would be awesome to merge this in 9.1!
I think I will rewrite to ACL SETUSER alice ^dbid this week. There's some talks about named databases and in that case something like ACL SETUSER alice ^db_name1 ^db_name2 looks better than ACL SETUSER bob db=db_name1,db_name2, what do you think?

madolson · 2025-10-27T14:54:58Z

In the discussion, it came up that we are missing the following other database features:

No database listed for ACL LOG
No database listed for MONITOR, you can parse this and track which is annoying
No database listed for COMMAND LOG
Monitor will show information for all databases. (Maybe fine)
Does FLUSHALL need all database access?
Do we need a DBLIST operation?
There was an ask to split pub/sub based off of databases, [NEW] Add complete isolation between databases (pub/sub) #1868.
Add support for named databases [NEW] Introduce database logical names #1601

codecov · 2025-10-27T15:13:59Z

Codecov Report

❌ Patch coverage is 90.59406% with 19 lines in your changes missing coverage. Please review.
✅ Project coverage is 72.32%. Comparing base (d16788e) to head (d35a3a7).

Files with missing lines	Patch %	Lines
src/module.c	8.33%	11 Missing ⚠️
src/acl.c	93.79%	8 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##           unstable    #2309      +/-   ##
============================================
- Coverage     72.45%   72.32%   -0.13%     
============================================
  Files           128      128              
  Lines         70485    70674     +189     
============================================
+ Hits          51068    51118      +50     
- Misses        19417    19556     +139

Files with missing lines	Coverage Δ
src/commands.def	`100.00% <ø> (ø)`
src/db.c	`93.35% <100.00%> (+0.19%)`	⬆️
src/intset.c	`100.00% <100.00%> (ø)`
src/lua/script_lua.c	`89.81% <100.00%> (+0.01%)`	⬆️
src/multi.c	`97.33% <100.00%> (+0.08%)`	⬆️
src/server.c	`88.43% <100.00%> (+0.03%)`	⬆️
src/server.h	`100.00% <ø> (ø)`
src/sort.c	`94.82% <100.00%> (+0.01%)`	⬆️
src/acl.c	`90.53% <93.79%> (+0.22%)`	⬆️
src/module.c	`9.77% <8.33%> (+<0.01%)`	⬆️

... and 10 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

madolson · 2025-10-27T15:20:04Z

The use cases we need to have clear syntax for.

User can add a databse to their existing supported databases

# Add DB 1 to user1s permissions
ACLSETUER user1 db+=1

User can remove a database from their accessible databases - Do we need to support this usecase?

ACLSETUER user1 db-=1,2,3

User can override all of their existing databases with new databases

ACLSETUER user1 resetdbs db+=1,2,3,4

@hpatro Will followup to try to help clarify the most consistent way to implement the syntax.

There is one more open question, do we want to make the default secure by default. For Redis 7, we changed the default permissions of an ACL user from allchannels to nochannels. Do we want to do the same thing here?

dvkashapov · 2025-10-27T16:17:26Z

Awesome! This is really descriptive and answers a lot of questions. Proposed syntax is good, I'm OK with it! Answering your first message:

ACL LOG, MONITOR, COMMANDLOG etc.

We can make an assumption that @admin commands need all database access to execute, seems to cover those cases but may be unintuitive, in this case we can return error with helpful message.

Monitor will show information for all databases

I will take a look at MONITOR implementation, maybe we can make it per-db with default of all databases.

Does FLUSHALL need all database access

Yes, FLUSHALL needs all database access.

Do we need a DBLIST operation?

DBLIST would be useful when we will have named databases, yes.

There was an ask to split pub/sub based off of databases

I don't know much about channels right now, so I can't say how hard it would be to make them per db.

Add support for named databases

In terms of ACL for named databases, if we decide to make them like an alias for some dbid, then implementation won't change much. We would only need to resolve name to dbid.

Do we want to make the default secure by default?

This will be good for security but it will be a breaking change for all existing ACL's for all users, maybe this is too much.

Important question: We're going with per-user permissions, not per-selector like currently in PR?

hpatro · 2025-10-27T18:02:15Z

We were just trying to think through in the weekly meeting what other gaps exists around databases support. @dvkashapov doesn't need to be worked upon regarding this change.

Important question: We're going with per-user permissions, not per-selector like currently in PR?

It's still per-selector, maybe the example suggested above brought in some ambiguity.

allenss-amazon · 2025-10-28T00:02:47Z

I started an issue for dealing with ACL issues for search module. #2764

Seems like this work intersects with that, in particular, the current search code would not enforce these ACL capabilities and would cause security issues.

dvkashapov · 2025-10-28T09:04:15Z

still per-selector

But then db+=1,2,3 would only apply to root selector, and will not be useful for user with >1 selector, same for db-=1,2,3 case. Do we want to give users ability to edit individual selector? Then we would need to identify them with some id's and add ACL LIST-SELECTORS user.

hpatro · 2025-10-28T17:13:39Z

still per-selector

But then db+=1,2,3 would only apply to root selector, and will not be useful for user with >1 selector, same for db-=1,2,3 case. Do we want to give users ability to edit individual selector?

That has been the case with all other restrictions (commands / categories / channels). We allow the operation even if one selector succeeds.

dvkashapov · 2025-10-29T06:21:56Z

OK, then I suggest we focus on db+=1,2,3 syntax, and while I do that - lets discuss db-=1,2,3, are we targeting to add more negative ACL's in future releases? If there's no request from community then maybe this is not needed?

Signed-off-by: Daniil Kashapov <[email protected]>

dvkashapov · 2025-11-15T15:37:18Z

@hpatro Thanks for the detailed points, I agree with them! However, I wonder if db level permissions configuration is necessary here? I suspect it might be a less common feature. Would love to hear your perspective on this.

In regards of the expected behaviour: current implementation fits all the criteria's, but we still lack test for ACL LOG, will do it and update the top comment!

Also AFAIK FLUSHDB and SCAN operate on current db, so we don't need to handle them in special way right now.

Signed-off-by: Daniil Kashapov <[email protected]>

dvkashapov · 2025-11-16T07:02:31Z

While writing test I noticed that for CMD_ALL_DBS we can't correctly set keyidxptr and as a result in ACL LOG object is cmd itself, should we leave it like that or use some placeholder?

Signed-off-by: Daniil Kashapov <[email protected]>

dvkashapov · 2025-11-16T13:40:30Z

@hpatro added VM_ACLCheckDbPermissions that checks db-level permissions for user, do we need anything else?
Also updated top comment.

Question: We need to handle db-level checks in VM_ACLCheckCommandPermissions because it calls ACLCheckAllUserCommandPerm which needs dbid, what should we do in this scenario?

ranshid · 2025-11-16T17:20:01Z

@dvkashapov I think probably want to also include migrate command destdb flag?
I assume when ACLs are synced cross the cluster it will probably fail on the target when we execute the select, but maybe it is better to fail it on the source as well?

Also cluster-migrateslots should have the ALL_DBS flag as this is also a cover-all-dbs command right?

src/acl.c

hpatro

Seems mostly good on acl.c barring the resetdbs behavior and code performance on each ACL SETUSER operation.

Going through the remaining files.

src/acl.c

hpatro · 2025-11-15T00:50:31Z

src/acl.c

+        selector->flags &= ~SELECTOR_FLAG_ALLDBS;
+    }
+
+    char *dblist = zstrdup(dbs_str);


Would suggest creating a sds and operate on it. improves strlen perf and more.

Rewrote to sds usage, PTAL

src/acl.c

hpatro · 2025-11-16T22:20:28Z

src/acl.c

    }
 }

 sds getAclErrorMessage(int acl_res, user *user, struct serverCommand *cmd, sds errored_val, int verbose) {


Not particular for this PR, . Was it a security requirement behind introducing a non-verbose mode and hide the user/resource from the error response ?

I also thought that it would be useful for user to know..

hpatro · 2025-11-16T22:22:39Z

@hpatro Thanks for the detailed points, I agree with them! However, I wonder if db level permissions configuration is necessary here? I suspect it might be a less common feature. Would love to hear your perspective on this.

In regards of the expected behaviour: current implementation fits all the criteria's, but we still lack test for ACL LOG, will do it and update the top comment!

Also AFAIK FLUSHDB and SCAN operate on current db, so we don't need to handle them in special way right now.

My bad. You're right SCAN is for the selected db. Let me update the comment. For FLUSHDB, for some weird reason I thought it takes in the dbid as parameter. So, you're right about this as well. :)

hpatro · 2025-11-16T22:25:52Z

@dvkashapov I think probably want to also include migrate command destdb flag? I assume when ACLs are synced cross the cluster it will probably fail on the target when we execute the select, but maybe it is better to fail it on the source as well?

I also think fail-fast is better.

Also cluster-migrateslots should have the ALL_DBS flag as this is also a cover-all-dbs command right?

Not sure about the behavior of this command. Does it use the already authenticated user to perform the operation ? Does it fail if the user doesn't have access to some keys in the keyspace? If yes, we should mark it to have ALL_DBS access.

hpatro · 2025-11-16T22:51:04Z

@hpatro added VM_ACLCheckDbPermissions that checks db-level permissions for user, do we need anything else? Also updated top comment.

Why would one use this check independently ?

Question: We need to handle db-level checks in VM_ACLCheckCommandPermissions because it calls ACLCheckAllUserCommandPerm which needs dbid, what should we do in this scenario?

There are two alternatives to deal with this.

Stop supporting the API with 9.1. We could alter the API or recommend module devs to use a new API VM_ACLCheckPermissions which takes in all the parameters required.
Structure our code in a way that still supports the existing API but the command isn't guaranteed to succeed if ACL database restriction feature is used.

I would recommend going with option 1. @allenss-amazon thoughts?

hpatro · 2025-11-16T22:52:50Z

@dvkashapov If you don't mind, I will update the top level comment with this #2309 (comment) as the checklist and other reviewers can signoff reading it and you can mark the checkbox as you finish implementing each of it.

src/acl.c

hpatro · 2025-11-17T00:24:59Z

src/acl.c

+        if (errno == ERANGE || endptr == token || *endptr != '\0' ||
+            dbid < 0 || dbid >= server.dbnum) {
+            return ACLDatabasePermissionError(new_dbs, dblist, EINVAL);
+        }


Would be better for user to understand what's incorrect in the command. WDYT ?

Current response is generic syntax error warning.

127.0.0.1:6379> config get databases 1) "databases" 2) "16" 127.0.0.1:6379> acl setuser hp db+=16 (error) ERR Error in ACL SETUSER modifier 'db+=16': Syntax error 127.0.0.1:6379> acl setuser hp db+=0 OK

True, will add new errno in this case.

src/acl.c

hpatro

Seems dangerous to set databases config to large value. The output buffer could be quite large and server processing time with setting acl setuser is also quite long with such high database count. This could be accounted as denial of service I believe.

% src/valkey-server --daemonize yes --logfile valkey.log --databases 100000000
% src/valkey-cli
127.0.0.1:6379> acl setuser hp on resetdbs db-=0
OK
(12.23s)
127.0.0.1:6379> acl list
<response too big and takes too long to get printed out>

hpatro · 2025-11-17T00:57:31Z

Did a dry run locally. Few things which caught my eyes.

Large database value seems dangerous and can block the main thread for long period Database-level access control #2309 (review)
~~2. ACL DB permission set flow misbehaves with allow and deny permission set in same operation Database-level access control #2309 (comment)~~
allow or deny permission beyond allowed db range throws generic error Database-level access control #2309 (comment)
~~4. Allow and deny permission leading to no db permission leads to empty allow db permission response instead of resetdbs Database-level access control #2309 (comment)~~
User connected to a database without permission won't be able to run any commands until selecting a database to which they have access to.

src/valkey-cli -a pass --user hp
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
127.0.0.1:6379> acl list
(error) NOPERM No permissions to access database
127.0.0.1:6379> select 1
OK
127.0.0.1:6379[1]> acl list
1) "user default on nopass sanitize-payload ~* &* alldbs +@all"
2) "user hp on nopass sanitize-payload resetchannels db+=1 +@all"

Signed-off-by: Daniil Kashapov <[email protected]>

dvkashapov

@hpatro Applied some of review suggestions, will get to work on the rest of them, PTAL at my comments.

src/acl.c

dvkashapov · 2025-11-17T00:59:27Z

src/acl.c

    }
 }

 sds getAclErrorMessage(int acl_res, user *user, struct serverCommand *cmd, sds errored_val, int verbose) {


I also thought that it would be useful for user to know..

src/acl.c

dvkashapov · 2025-11-17T05:19:30Z

src/acl.c

+        if (errno == ERANGE || endptr == token || *endptr != '\0' ||
+            dbid < 0 || dbid >= server.dbnum) {
+            return ACLDatabasePermissionError(new_dbs, dblist, EINVAL);
+        }


True, will add new errno in this case.

Signed-off-by: Daniil Kashapov <[email protected]>

dvkashapov · 2025-11-17T07:19:42Z

There are two alternatives to deal with this.

Stop supporting the API with 9.1. We could alter the API or recommend module devs to use a new API >VM_ACLCheckPermissions which takes in all the parameters required.

Structure our code in a way that still supports the existing API but the command isn't guaranteed to succeed if ACL >database restriction feature is used.
I would recommend going with option 1. @allenss-amazon thoughts?

I'm OK with first way, but I guess this is another major decision and we need feedback from community on that one.
We should probably discuss this on weekly meeting, wdyt?

Signed-off-by: Daniil Kashapov <[email protected]>

madolson · 2025-11-17T17:06:53Z

Decisions from the core meeting:

I would like us to stick to alldbs permissions though.
1. Seems like the right decision.
What should the initial syntax of settings databases.
1. We will start with just db=<id1>,<id2>
Behavior of being in a database without having permissions
1. As long as command is not accessing the keyspace, allow.
2. Need to double check keyless commands.
Module APIs
1. We should implement a new top level API that also passes in the database. Other APIs are maybe TBD.

Signed-off-by: Daniil Kashapov <[email protected]>

hwware added the major-decision-pending Major decision pending by TSC team label Jul 4, 2025

madolson reviewed Jul 7, 2025

View reviewed changes

src/acl.c Outdated Show resolved Hide resolved

src/module.c Outdated Show resolved Hide resolved

src/multi.c Show resolved Hide resolved

dvkashapov marked this pull request as ready for review July 14, 2025 14:22

madolson requested a review from hpatro July 14, 2025 14:54

dvkashapov mentioned this pull request Jul 15, 2025

valkey-cli: Fix dbid reset after error in MULTI #2357

Closed

hpatro reviewed Jul 31, 2025

View reviewed changes

madolson added this to Valkey 9.1 Aug 4, 2025

madolson moved this to Optional for next release candidate in Valkey 9.1 Aug 4, 2025

madolson moved this from Optional for next release candidate to Todo in Valkey 9.1 Aug 6, 2025

dvkashapov mentioned this pull request Oct 6, 2025

Add ValkeyModule_ACLCheckCommandPermissionsForCurrentUser API #2690

Draft

dvkashapov added 3 commits October 21, 2025 16:38

Fix selector flag assignment and apply clang-format

97a27c5

Signed-off-by: Daniil Kashapov <[email protected]>

Extend serverCommand with get_dbid_args, unify ACL checks

b2fd61a

Signed-off-by: Daniil Kashapov <[email protected]>

dvkashapov force-pushed the unstable branch from e3eca62 to b2fd61a Compare October 21, 2025 11:46

Run generate commands

b4adb23

Signed-off-by: Daniil Kashapov <[email protected]>

dvkashapov added 2 commits November 16, 2025 11:54

Fix reason in ACL LOG and add test

15068cf

Signed-off-by: Daniil Kashapov <[email protected]>

Use cmd->fullname when no argpos

ec93e49

Signed-off-by: Daniil Kashapov <[email protected]>

Add module api for db-level check and test

711b4f3

Signed-off-by: Daniil Kashapov <[email protected]>

ranshid reviewed Nov 16, 2025

View reviewed changes

src/acl.c Show resolved Hide resolved

hpatro reviewed Nov 16, 2025

View reviewed changes

hpatro reviewed Nov 17, 2025

View reviewed changes

src/acl.c Outdated Show resolved Hide resolved

hpatro reviewed Nov 17, 2025

View reviewed changes

src/acl.c Outdated Show resolved Hide resolved

hpatro reviewed Nov 17, 2025

View reviewed changes

apply pr suggestions

fc5bc3a

Signed-off-by: Daniil Kashapov <[email protected]>

dvkashapov commented Nov 17, 2025

View reviewed changes

apply clang-format

10d7499

Signed-off-by: Daniil Kashapov <[email protected]>

add ALL_DBS flag to migration/slot commands

7f0e020

Signed-off-by: Daniil Kashapov <[email protected]>

madolson moved this from Todo to In Progress in Valkey 9.1 Nov 17, 2025

dvkashapov added 5 commits November 26, 2025 13:14

db= syntax, acl getuser support

b6ab15b

Signed-off-by: Daniil Kashapov <[email protected]>

Return ACL_DENIED_DB only for R/W commands in forbidden db

0562230

Signed-off-by: Daniil Kashapov <[email protected]>

Use sds

04568af

Signed-off-by: Daniil Kashapov <[email protected]>

Merge remote-tracking branch 'upstream/unstable' into unstable

19186e7

Signed-off-by: Daniil Kashapov <[email protected]>

Merge remote-tracking branch 'upstream/unstable' into unstable

d35a3a7

Signed-off-by: Daniil Kashapov <[email protected]>

Database-level access control #2309

Are you sure you want to change the base?

Database-level access control #2309

Conversation

dvkashapov commented Jul 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

API changes and user behavior:

Database Permissions (db=)

Open Issues

Uh oh!

dvkashapov commented Jul 4, 2025

Uh oh!

hwware commented Jul 4, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

madolson commented Jul 14, 2025

Uh oh!

hpatro left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

dvkashapov commented Aug 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

madolson commented Sep 3, 2025

Uh oh!

dvkashapov commented Oct 21, 2025

Uh oh!

madolson commented Oct 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecov bot commented Oct 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

madolson commented Oct 27, 2025

Uh oh!

dvkashapov commented Oct 27, 2025

Uh oh!

hpatro commented Oct 27, 2025

Uh oh!

allenss-amazon commented Oct 28, 2025

Uh oh!

dvkashapov commented Oct 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hpatro commented Oct 28, 2025

Uh oh!

dvkashapov commented Oct 29, 2025

Uh oh!

dvkashapov commented Nov 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dvkashapov commented Nov 16, 2025

Uh oh!

dvkashapov commented Nov 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ranshid commented Nov 16, 2025

Uh oh!

Uh oh!

hpatro left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

dvkashapov commented Jul 4, 2025 •

edited

Loading

Database Permissions (`db=`)

dvkashapov commented Aug 1, 2025 •

edited

Loading

madolson commented Oct 27, 2025 •

edited

Loading

codecov bot commented Oct 27, 2025 •

edited

Loading

dvkashapov commented Oct 28, 2025 •

edited

Loading

dvkashapov commented Nov 15, 2025 •

edited

Loading

dvkashapov commented Nov 16, 2025 •

edited

Loading

hpatro left a comment •

edited

Loading

hpatro commented Nov 16, 2025 •

edited

Loading

hpatro commented Nov 16, 2025 •

edited

Loading

hpatro left a comment •

edited

Loading

hpatro commented Nov 17, 2025 •

edited

Loading

dvkashapov commented Nov 17, 2025 •

edited

Loading