Currently migrating to snowflake from another relational database. Below are the SQL commands that we used in attempt to grant the right permissions. When attempting to create the stored procedure in the DEVELOPER_ARCHIVE database and LANDING_ZONE schema using the DEVELOPER_ROLE, we get an error that we don't have the permissions.
CREATE ROLE IF NOT EXISTS DEVELOPER_ROLE;
CREATE ROLE IF NOT EXISTS DEVELOPER_CRUD_ROLE;
CREATE ROLE IF NOT EXISTS DEVELOPER_READONLY_ROLE;
GRANT ROLE DEVELOPER_READONLY_ROLE TO role DEVELOPER_CRUD_ROLE;
GRANT USAGE ON DATABASE DEVELOPER_ARCHIVE to DEVEVELOPER_CRUD_ROLE;
The role will also need usage on the LANDING_ZONE schema and an additional create procedure grant. Here is a link to the grants documentation (schemaPrivileges);
https://docs.snowflake.com/en/sql-reference/sql/grant-privilege.html
Related
I was given access to a database (turtwig) in Neo4j created by a colleage, who gave me the default role 'PUBLIC' and a custom one called 'modeller'. I am triying to create a new node label but I get this message:
Node label error
When I try to give myself the privilage to create node labels, an error occurs:GRANT ERROR. This same error occurs when I try to grant myself the privileges of assigning privileges with GRANT ASSIGN PRIVILEGE ON DBMS TO modeller
Run this command and you will see the privileges that user modeller has.
SHOW USER PRIVILEGES
Granting yourself (as modeller) access for that privilege should be done by admin. Then you should ask your database admin (or colleague) to grant you access to create new nodes.
GRANT CREATE ON GRAPH turtwig ELEMENTS * TO modeller
How to configure a PSQL v11.4 user that is not the superuser and does not own the database.
This user should have full access to create SQL objects and drop them, even
though they do not own the database, so they can not drop the database.
All sql/database objects exist on the PUBLIC schema.
So far I have tried:
CREATE USER app_user WITH ENCRYPTED PASSWORD 'foo_bar';
ALTER USER app_user NOCREATEDB NOCREATEROLE;
ALTER USER app_user VALID UNTIL 'infinity';
GRANT ALL PRIVILEGES ON DATABASE database TO app_user;
When running Rails migrations I get the following error:
remote: PG::InsufficientPrivilege: ERROR: permission denied for table schema_migrations
Seems like the psql best practices is to have a role with privileges
set, then assign the user to be a member of that role. However because everything
is on the public schema all users/roles should have full access right? However
this line in the docs is throwing me off:
"The right to drop an object, or to alter its definition in any way, is not treated as a grantable privilege; it is inherent in the owner, and cannot be granted or revoked. (However, a similar effect can be obtained by granting or revoking membership in the role that owns the object; see below.) The owner implicitly has all grant options for the object, too."
from: https://www.postgresql.org/docs/11/sql-grant.html
Also though because the database is being restored via the sudo user, objects
will be owned by the sudo user, however new objects could belong to the
app_user, is this an issue?
You need the CREATE privilege on the database, and you need to pg_dump (or pg_restore with the -x and -O options, so that the restoring user becomes the object owner and no additional privileges are granted.
Some things, like certain extensions, event triggers or functions in untrusted languages (to name a few examples) require superuser rights to create them. Either avoid such objects or create them ahead of time and ignore the errors.
As I read, there are certain access privileges given to a user or role in Informix. If I give any of the database level privilege, it will have access to all users/ schemas under that database.
My doubt was that can I restrict this privilege to specific users/ schemas in that database? Do we have any user/schema level privilege in Informix?
If you grant a user CONNECT privilege to a database, then they can access tables within that database for which they have been granted access (which is typically, but not necessarily, all tables in the database). You can also revoke PUBLIC privileges on a table, and then grant access only to named users or roles, and then only those users who have been granted access can access it. Here, "access" means "if they try to SELECT, they need to have been granted SELECT access; if they try to INSERT, they need to have been granted INSERT access; etc.".
By default, when you create a table in an ordinary database, then all users are given select, insert, update, delete privileges on the table. This is done via the equivalent of GRANT ALL ON the_table TO PUBLIC. Note that every user has the permissions granted to PUBLIC, and possibly some extra privileges. Therefore, to ensure only selected users or roles have access, it is necessary to use REVOKE ALL ON the_table FROM PUBLIC. There is an environment variable NODEFDAC=1 and a $ONCONFIG file setting with the same name that suppresses the default 'discretionary access controls' (DAC) granted to PUBLIC. Note that in a MODE ANSI database, no permissions are granted to anyone else by default.
The constraints on users granted RESOURCE privilege in a database are similar users granted CONNECT privilege — the difference is that RESOURCE users can create their own tables, whereas CONNECT users cannot.
If a user is granted DBA privilege, they can access any tables in the database. Be cautious about granting DBA privilege, therefore.
I recently added a stored procedure to my SQL Azure database. I added that procedure logged in as username1. However, I need to allow username2 the ability to EXECUTE that stored procedure. From what I can tell, username2 cannot see/execute the stored procedure. However, username1 can.
What command do I need to run to allow username2 to execute my stored procedure? I'm confident that it's GRANT. However, I'm not sure of the syntax. Can someone please give me an example?
You have the same options as if you where using an SQL Server database. You need to GRANT the user proper privileges. Log in as username1 and execute the following:
GRANT EXECUTE ON Nameofyourprocedure TO username2;
For more help on Azure SQL syntax and limitations refer to the following link:
http://msdn.microsoft.com/en-us/library/windowsazure/ee336226
I am using FireBird 2.1 and I have a user and a role. I granted execute permission on an stored procedure to role but not to user.
When I am trying to execute the stored procedure while logged in as a user with the role, I am getting following error:
Statement #1: no permission for execute access to PROCEDURE SPSELECTMANAGERS.
I checked the roles and users, the user is already added in the roles.
Is the SP recursive? In that case the procedure must have granted right to execute itself, ie add this to the DB creation script:
GRANT EXECUTE ON PROCEDURE SPSELECTMANAGERS TO PROCEDURE SPSELECTMANAGERS;
BTW this behaviour is considered to be a bug and will be fixed in future version (FB 3).