About console configuration and roles

I deployed the Nebula Graph services with Docker Compose, as described in this article.

When the last command docker run --rm -ti --network=host vesoft/nebula-console:nightly --addr=127.0.0.1 --port=3699 is run, the connection to the graph service is successful. But I found something weird when I granted a role to a user.

For example, I created a space named test1 and a user named user2, and granted the GUEST role to user2 in the test1 space. Then I connected to the graph service by running this command docker run --rm -ti --network=host vesoft/nebula-console:nightly --addr=127.0.0.1 --port=3699 --u="user2" (The --u="user2" configuration is from the “Console Configurations”. I hope it is right). When I ran the SHOW ROLES IN test1 statement, it works - only user2 and its role are shown. But when I run the CREATE TAG team(name, string) statement, it was supposed to fail, but actually the tag was created. According to the “Built-in Roles” article, a guest must not write schema. So which one is right?

Thanks for asking. Did you enable the authorization parameter?

Set the enable_authorize parameter in the /usr/local/nebula/etc/nebula-graphd.conf file to true to enable the authorization.

See the built-in roles doc.

Do remember to restart the services after modifying the configurations. Let me know if this helps.

Before the enable_authorize configuration, granting a role to an account cannot work well?

If you dont set enable_authorize, you can create user and grant roles because authorization is not work. But after enable_authorize is set, roles will be checked.

Yeah, I changed the enable_authorize configuration and the granting role works. So many thanks.

But I think I may find another thing.

I changed the role of the root to GUEST. Then today, when I logged in the console as the root account, I can still create user and seems granting role does work, but when I want to show all the roles in the space, I cannot see anything but the role of root, as shown in this screenshot. I don’t know why, but I think you may want to know this information :slight_smile:

image

I suspect the problem is caused by create users or grant role when enable_authorize is turned off. Because if enable_authorize was turned off, authorize operations are not validated, which can lead to metadata confusion. so clean up these invalid data through REVOKE statement as well.

1 Like

Got it. Thanks so much.