I've come across this mystery in some SQL Server code I've inherited:
GRANT INSERT TO SomeUserRole
I would expect there to have to be a table or view to be specified. Running this works fine but doesn't appear to do anything. The role doesn't have rights to insert into any tables. Any ideas? I'd like to get rid of this if possible but if it is somehow giving the role some access, I'll have to keep it.
Thanks
Joe
The grammar at MSDN shows that the only required clauses are GRANT TO when used at the database level. There is no syntax at that level that restricts it to a specific table.
GRANT <permission> [ ,...n ]
TO <database_principal> [ ,...n ] [ WITH GRANT OPTION ]
[ AS <database_principal> ]
<permission>::=
permission | ALL [ PRIVILEGES ]
<database_principal> ::=
Database_user
| Database_role
| Application_role
| Database_user_mapped_to_Windows_User
| Database_user_mapped_to_Windows_Group
| Database_user_mapped_to_certificate
| Database_user_mapped_to_asymmetric_key
| Database_user_with_no_login
Related
Hopefully someone can help me, when the developer queried to insert data, it gives the following error.
1142 - INSERT command denied to user 'db_user'#'localhost' for table 'table_name'
I checked user privileges, the user is granted for all the permissions:
MariaDB [(none)]> show grants for 'db_user'#'localhost';
+-------------------------------------------------------------------------------------------------------------+
| Grants for db_user#localhost |
+-------------------------------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO `db_user`#`localhost` IDENTIFIED BY PASSWORD '*8FBC7CD05DD7354A9EAD92EC508E27E334FE' |
| GRANT ALL PRIVILEGES ON `db`.* TO `db_user`#`localhost` |
+-------------------------------------------------------------------------------------------------------------+
How can I resolve the issue?
"USAGE grants no real privileges". Its a confusing name. So more GRANT is needed:
GRANT INSERT ON dbname.table_name TO db_user#localhost;
How can I verify the privileges after granting the following to the read_only_user?
alter default privileges for role read_only_user grant all on tables to foodapp;
You can run this query to get default privileges:
SELECT
defaclrole::regrole,
defaclnamespace::regnamespace,
CASE defaclobjtype
WHEN 'r' THEN 'relation'
WHEN 'S' THEN 'sequence'
WHEN 'f' THEN 'function'
WHEN 'T' THEN 'type'
WHEN 'n' THEN 'schema'
END,
(aclexplode(defaclacl)).*
FROM pg_default_acl;
And then add a WHERE clause for the user if you want to filter it.
Or in psql you can use:
\\ddp
Your question is seems interesting. I'm mentioning some ways below please read carefully and try it in your system. Some of them might help you. :)
You can do that by following:
In One line
postgres=> \l
This command will display the information you're looking for.
like this.
postgres=> \l
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
-----------+----------+----------+-------------+-------------+-----------------------
postgres | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
template0 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres +
| | | | | postgres=CTc/postgres
template1 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres +
| | | | | postgres=CTc/postgres
The docs on Privileges give an explanation of how to interpret the output. For specific privileges on a table of the current database, use \z myTable.
Undercovers psql uses the bellow query when you issue \du command.
SELECT r.rolname, r.rolsuper, r.rolinherit,
r.rolcreaterole, r.rolcreatedb, r.rolcanlogin,
r.rolconnlimit, r.rolvaliduntil,
ARRAY(SELECT b.rolname
FROM pg_catalog.pg_auth_members m
JOIN pg_catalog.pg_roles b ON (m.roleid = b.oid)
WHERE m.member = r.oid) as memberof
, r.rolreplication
, r.rolbypassrls
FROM pg_catalog.pg_roles r
WHERE r.rolname !~ '^pg_'
ORDER BY 1;
In the case of the table.
SELECT grantee, privilege_type
FROM information_schema.role_table_grants
WHERE table_name='mytable'
This gives you this kind of output:
mail=# select grantee, privilege_type from information_schema.role_table_grants where table_name='aliases';
grantee | privilege_type
--------------+-----------------
mailreader | INSERT
mailreader | SELECT
mailreader | UPDATE
mailreader | DELETE
mailreader | TRUNCATE
mailreader | REFERENCES
mailreader | TRIGGER
(7 rows)
mail=#
Note that (at least under Postgres 9.4) the above will not work for materialized views.
Using psql meta-commands:
https://www.postgresql.org/docs/current/static/app-psql.html
Going over the page with Ctrl+F gives:
\ddp [ pattern ]
Lists default access privilege settings.
\dp [ pattern ] Lists tables, views and sequences with their
associated access privileges.
\l[+] [ pattern ] List the databases in the server and show...
access privileges.
Also mentioned above, but not found with word "privileges" on the manual page:
\du+ for roles with login and \dg+ for roles without - will have a filed "Member of" where you find roles granted to roles.
I deliberately skip function and language privileges here, found in psql manual as barely manipulated (and if you do use those privileges you won't come here for advice). same for user-defined types, domains, and so on - using "+" after the meta-command will show you privileges if applicable.
A little extreme way to check the privileges is dropping the user in the transaction, e.g.:
s=# begin; drop user x;
BEGIN
Time: 0.124 ms
ERROR: role "x" cannot be dropped because some objects depend on it
DETAIL: privileges for type "SO dT"
privileges for sequence so
privileges for schema bin
privileges for table xx
privileges for table "csTest"
privileges for table tmp_x
privileges for table s1
privileges for table test
Time: 0.211 ms
s=# rollback;
ROLLBACK
Time: 0.150 ms
When the list is longer than N, (at least in 9.3), the warning with the list of privileges is collapsed, but you still can find it full in logs...
I am writing a procedure that is going to create objects (views) across multiple schemas where those views need to have different owners. I want the procedure to GRANT OWNERSHIP to the appropriate role after it creates the view, but my newly created DEV_PROC_ROLE which is used to create and maintain procedures cannot execute GRANT OWNERSHIP. Our higher level roles can, but I don't want the procedure to be managed and executed up at that level.
Here's some context
https://docs.snowflake.net/manuals/sql-reference/sql/grant-ownership.html
"A role that has the MANAGE GRANTS privilege can transfer ownership of an object to any role; in contrast, a role that does not have the MANAGE GRANTS privilege can only transfer ownership from itself to a child role within the role hierarchy."
So what command do I need to execute in my higher level role to give the MANAGE GRANTS privilege to the DEV_PROC_ROLE?
I cannot find in the documentation how to grant the MANAGE GRANTS privilege to a role.
Note - once the DEV_PROC_ROLE can grant ownership, it will issue a command like this to change the ownership and retain all of the Future Select priv's of other roles setup against that schema. GRANT OWNERSHIP ON VIEW TO ROLE COPY CURRENT GRANTS;
In the document https://docs.snowflake.net/manuals/sql-reference/sql/grant-privilege.html , you can find the syntax:
GRANT { { globalPrivileges | ALL [ PRIVILEGES ] } ON ACCOUNT
| { accountObjectPrivileges | ALL [ PRIVILEGES ] } ON { RESOURCE MONITOR | WAREHOUSE | DATABASE | INTEGRATION } <object_name>
| { schemaPrivileges | ALL [ PRIVILEGES ] } ON { SCHEMA <schema_name> | ALL SCHEMAS IN DATABASE <db_name> }
| { schemaObjectPrivileges | ALL [ PRIVILEGES ] } ON { <object_type> <object_name> | ALL <object_type>S IN SCHEMA <schema_name> }
| { schemaObjectPrivileges | ALL [ PRIVILEGES ] } ON FUTURE <object_type>S IN SCHEMA <schema_name>
}
TO [ ROLE ] <role_name> [ WITH GRANT OPTION ]
Where globalPrivileges
globalPrivileges ::=
{ { CREATE { ROLE | USER | WAREHOUSE | DATABASE | INTEGRATION } } | MANAGE GRANTS | MONITOR USAGE } [ , ... ]
So basically, you can do GRANT MANAGE GRANTS ON ACCOUNT TO DEV_PROC_ROLE to grant the MANAGE GRANTS privilege to the DEV_PROC_ROLE.
What could be [ OBJECT :: ][ schema_name ]. object_name in the
GRANT <permission> [ ,...n ] ON
[ OBJECT :: ][ schema_name ]. object_name [ ( column [ ,...n ] ) ]
TO <database_principal> [ ,...n ]
[ WITH GRANT OPTION ]
[ AS <database_principal> ]
Could it be a table or view?
OBJECT here refers to any of the things that exist in sys.objects. From the documentation for sys.objects, that could be any of
AGGREGATE_FUNCTION
CHECK_CONSTRAINT
CLR_SCALAR_FUNCTION
CLR_STORED_PROCEDURE
CLR_TABLE_VALUED_FUNCTION
CLR_TRIGGER
DEFAULT_CONSTRAINT
EXTENDED_STORED_PROCEDURE
FOREIGN_KEY_CONSTRAINT
INTERNAL_TABLE
PLAN_GUIDE
PRIMARY_KEY_CONSTRAINT
REPLICATION_FILTER_PROCEDURE
RULE
SEQUENCE_OBJECT
SERVICE_QUEUE
SQL_INLINE_TABLE_VALUED_FUNCTION
SQL_SCALAR_FUNCTION
SQL_STORED_PROCEDURE
SQL_TABLE_VALUED_FUNCTION
SQL_TRIGGER
SYNONYM
SYSTEM_TABLE
TABLE_TYPE
UNIQUE_CONSTRAINT
USER_TABLE
VIEW
Mind you, not every permission makes sense for every type of object. For instance, you can't grant execute permission to a table. Indeed, not every object type can be the target of a grant (primary keys, for instance). The documentation for grant has a nice list near the bottom of each type of securable and link to a documentation page for what permissions can be granted to it.
I'm not entirely sure if this is what you're asking, but the OBJECT :: keyword here isn't meant to be replaced by some sort of identifier such as TABLE ::, it's meant to be specified literally as OBJECT ::. It's used to indicate that you want to grant permissions to an object as opposed to, say, a schema. According to this page, an object is any schema-level securable, such as a table, view, stored procedure, sequence, etc.
Also according to that page, the OBJECT :: keyword is optional if schema_name is specified. That leads me to believe that the need for specifying OBJECT :: is simply to make sure the database it's what type of entity the permissions are being granted to, since permissions can be granted to objects, schemas, server principles, and more.
I need to make some permission changes on a MS SQL server (2005) database. Some tables read only for all but dbo, some tables read-write for all etc. In the past I used the management program that came on the SQL server disk. That is not an option for me right now. I cannot find a place in visual studio to alter table permissions. Does visual studio have that feature?
Can you download SQL Server Management Studio Express?
GRANT for tables:
GRANT <permission> [ ,...n ] ON
[ OBJECT :: ][ schema_name ]. object_name [ ( column [ ,...n ] ) ]
TO <database_principal> [ ,...n ]
[ WITH GRANT OPTION ]
[ AS <database_principal> ]
<permission> ::=
ALL [ PRIVILEGES ] | permission [ ( column [ ,...n ] ) ]
<database_principal> ::=
Database_user
| Database_role
| Application_role
| Database_user_mapped_to_Windows_User
| Database_user_mapped_to_Windows_Group
| Database_user_mapped_to_certificate
| Database_user_mapped_to_asymmetric_key
| Database_user_with_no_login
example:
GRANT SELECT ON dbo.YourTable TO YourUser
GRANT INSERT ON dbo.YourTable TO YourUser
GRANT DELETE ON dbo.YourTable TO YourUser
Visual Studio 2008 does not have this ability and I don't see it included in the future editions either.
you could always use the command line to alter the permissions.