Bug: Table Permissions Doesn't Seem To Be Working With Embedded Select Statement about surrealdb

[gguillemas]

Got it! I missed that detail when reading the issue.

I understand you approach. You are relying on the permissions clause for SELECT only allowing the user to query their own record in order to retrieve only their user with ONLY and LIMIT 1 in the function.

Unfortunately, the current behavior in SurrealDB (#2161) leads to permissions clauses being able to read any data, causing your statement to simply return the first user record instead of the record belonging to the authenticated user. We are discussing this behavior as well as some related bugs in the context of a security issue in GHSA-9722-9j67-vjcr, and a fix that may change this behavior is currently being developed by the team responsible.

Thank you again for reporting this, I will keep this issue open and update it when this is resolved.

For the time being, a potential alternative could be to use another unique user identifier already present on the token (e.g. email) to use internally as either a custom record identifier for user or just as a normal field of the user record that is also present in post and like in order to allow the relation.

---

For future reference, here is a simplified scenario that reproduces this issue:

USE NS test DB test;
DEFINE TABLE user PERMISSIONS FOR SELECT WHERE name = $auth.name;
DEFINE TABLE post PERMISSIONS FOR SELECT WHERE user = (SELECT id FROM ONLY user LIMIT 1).id;
CREATE user:a CONTENT {"name": "a"};
CREATE user:b CONTENT {"name": "b"};
CREATE post:a CONTENT {"user": user:a};
CREATE post:b CONTENT {"user": user:b};
DEFINE SCOPE user
  SESSION 1d
  SIGNIN (SELECT * FROM user WHERE name = $name)
  SIGNUP (CREATE user CONTENT {"name": $name})
;

Then, I sign in as user:a and run the following:

SELECT * FROM post;
[
	{
		id: post:a,
		user: user:a
	}
]

I get the correct post for that user, great!
Then, I sign in as user:b and run the following:

SELECT * FROM post;
[
	{
		id: post:a,
		user: user:a
	}
]

I get the same post. It seems that the SELECT id FROM ONLY user LIMIT 1 statement is always returning the first user.
To test this hypothesis, we create a new user with a numeric identifier and their own post from a root session:

CREATE user:1 CONTENT {"name": 1};
[[{ id: user:1, name: 1 }]]
CREATE post:1 CONTENT {"user": user:1};
[[{ id: post:1, user: user:1 }]]

If our hypothesis is correct, selecting posts as any scope user should now return the post of user:1.
We sign in again as user:a and run the following:

SELECT * FROM post;
[
	{
		id: post:1,
		user: user:1
	}
]

We sign in again as user:b and run the following:

SELECT * FROM post;
[
	{
		id: post:1,
		user: user:1
	}
]

It seems that our hypothesis is correct. The permissions clause has access to all users and will always return the first one.

[gguillemas]

Hi @ReziaBanks! Thank you for taking the time to write a detailed report for this issue you are experiencing. I will try to reproduce your scenario whenever I have a moment. For the time being, may I ask why not use FOR CREATE, DELETE WHERE $scope = 'user' AND in = $auth.id? Using $auth.id is the default way of accessing the record identifier of the authenticated user. Is there a particular reason why you prefer to rely on a custom function for that?

[ReziaBanks]

I'm using Auth0 as my Authentication Provider, therefore the $auth variable returns NONE. Snippet from the Auth0 implementation tutorial.

It is also important to note that the $auth variable accessible from SurrealQL will not contain any values in this case, as it requires the id claim to be added to the JWT, containing the value of the identifier of a SurrealDB record. For the current example, the $auth variable will not be necessary.

[ReziaBanks]

Thanks for the breakdown, adding a WHERE clause to the CURRENT USER function solved the issue.

I think it would be helpful to add context (doesn't use scope permission in a scoped connection) on PERMISSIONS in the documentation.

[gguillemas]

I agree that this behavior should be documented. Since we are currently in the process of redefining exactly how we want PERMISSIONS clauses to behave, I will make sure that the outcome is documented whenever a decision is made 👍

Thank you again for opening this issue!