I ran into a peculiar problem with my database that I haven't been able to solve since yesterday.
So I created a user that has access to the function "write_match_history()" and access to the table "match_history," and I can use this user to query match history as well as write to it directly using sql. However, when I try to run "write_match_history," I get the following error:
error: error: permission denied for relation match_history
Here are the accesses I've granted to this user:
drop OWNED by d_write;
drop user if exists d_write;
create user d_write with encrypted password 'supersecret';
grant execute on function write_match_history(a,b,c,d,e,f) to d_write;
grant usage on schema d to d_write;
grant insert on table d.match_history to d_write;
grant select on table d.match_history to d_write;
grant select on all SEQUENCES in SCHEME d to d_write;
grant insert on all tables in schema d to d_write;
grant select on all talbes in schema d to d_write;
These permissions are everything I've tried so far. Let me know if you need more information.
Thanks!
Well, what is the owner of the function write_match_history(a,b,c,d,e,f). Do it allow to insert/update on table match_history. If not, please try it. I think the problem is here.
Related
I don't want to execute the stored procedure with admin privileges or with the instance owner. I am looking for the minimum permissions required to execute an undocumented stored procedure called SYSPROC.DB2LK_GENERATE_DDL for extracting the DDL statements from a DB2 database.
For example: I tried with SELECT and EXCEUTE permissions but it's not working:
db2 grant SELECT on SYSTOOLS.DB2LOOK_INFO to user devuser
db2 grant execute on procedure SYSPROC.DB2LK_GENERATE_DDL to user devuser`
You should call this routine once as some administrative user with appropriate privileges to create necessary objects implicitly in the database.
Grant the following privileges to your user afterwards.
grant usage on sequence SYSTOOLS.DB2LOOK_TOKEN to user myuser;
grant select on table SYSTOOLS.DB2LOOK_INFO_V to user myuser;
grant select, update, delete, insert on table SYSTOOLS.DB2LOOK_INFO to user myuser;
New to Pg from MS SQL side where to restrict access simply grant EXE permission to Functions and SPs. So created a user/role, set its search_path to a dedicated schema of a database, grant EXECUTE ON ALL FUNCTIONS IN SCHEMA myschema. Tried execute a function got
permission denied for schema myschema
Ok, grant usage on schema myschema to role. The function does a select ... from mytable so now
permission denied for table mytable
To grant SELECT on my table? Wait, purpose of this function is to restrict the role from exploring tables.
Your situation is: User a owns a table mytable in a schema myschema. User b initially has no permissions on either. Now you want to allow b limited access to mytable. Granting SELECT on the table would be too much — you want to grant access only through a special function myfunction.
Then you need a function that does not run with the permissions of the caller (SECURITY INVOKER), which would be the default, but with the permissions of the function owner (SECURITY DEFINER). Then user a should run:
CREATE FUNCTION public.read_mytable(...) RETURNS ...
LANGUAGE ...
/* runs with the privileges of the owner */
SECURITY DEFINER
/* important: force "search_path" to a fixed order */
SET search_path = pg_catalog,pg_temp
AS $$...$$;
/* by default, everybody can execute a function */
REVOKE EXECUTE ON FUNCTION public.read_mytable FROM PUBLIC;
GRANT EXECUTE ON FUNCTION public.read_mytable TO b;
Note that I created the function in schema public, to which b has access (don't forget to REVOKE CREATE ON SCHEMA public FROM PUBLIC;!).
Setting a search_path for user b is not enough, since this can always be changed dynamically with the SET command. You don't want b to run a privilege escalation attack.
So I'm making this app and I'm using Postgres and I've already created a database, a user and a password and granted all privileges on the database to the user I've created.
The thing is, when I switch the database in psql using \c <database_name> I get in just fine and can use queries on it.
But when I run psql using postgres://user_name:password#localhost:5432/databasename on terminal and try to select * from the <table_name> it gives me this message
permission denied for relation <table_name>
Can you please tell me what to do, I've had this problem before and I had to create another database or change the user but I want a better solution please.
PS: I've tried to use this :
GRANT ALL PRIVILEGES ON TABLE <table_name> to <user_name>
This is how I created and accessed my database:
rawan95=# create database food ;
CREATE DATABASE
rawan95=# create user meal with password '123';
CREATE ROLE
rawan95=# grant all privileges on database food to meal;
GRANT
rawan95=# \c food
You are now connected to database "food" as user "rawan95".
After that, I've built it using
food=# \i src/database/db_build.sql
BEGIN
DROP TABLE
CREATE TABLE
INSERT 0 1
COMMIT
Then I selected data from the table just fine, but when I try to access it using this, I get an error: psql postgres://meal:123#localhost:5432/food
food=> select * from foods;
ERROR: permission denied for relation foods
You are granting the privileges before you create the tables.
As there are no tables at that moment nothing is granted. The tables you created are not owned by the user meal but the user rawan95 (which the \c command told you).
Plus: granting "all privileges" on a database, does not grant any select privilege. As documented in the manual "all privileges" are: CREATE, CONNECT, TEMPORARY, TEMP. The CREATE privilege would allow the user meal to create tables in that database.
If you want all those tables to be owned by the user meal you need to run your setup script after you connected as the user meal (the \c command did not change the current user)
If you do want rawan95 to be the owner of the tables, you need to either grant the select privilege after creating all tables:
grant select on all tables in schema public to meal;
Or, you can change the default privilege before creating the tables (before running db_build.sql), so that they are applied to all tables in the future:
alter default privileges in schema public
grant select on all tables to meal;
The alter default privileges only has an effect for tables that are created after that. So to fix your current setup, you need to first grant select on the existing tables, and the change the default privileges for all tables that are created in the future.
Have you granted usage on the schema? Without that the table permissions are useless.
GRANT USAGE ON SCHEMA schema_name TO username
EDIT: Based on comment thread below we have established.
The table is in public schema.
The table belongs to rawan95 but the schema does not (public schema belongs to root postgres user).
The OP is attempting to connect and access the table as user 'meal' they have granted table permissions using the rawan95 user but are unable to grant schema permissions.
From the above, the problem could still be that the user 'meal' does not have usage on the public schema. If you are on Linux the quickest way to sort this is to switch to the super user to make this change from terminal:
sudo -u postgres psql -c "GRANT USAGE ON SCHEMA public TO meal"
FURTHER EDIT - having read your new clarification this is not correct (or at least not useful). The issue is as pointed out by the other answerer that you didn't have a table at the time you did the grant.
Logged in as the superuser, how can I grant user access to a specific table under a specific schema.
I tried this
GRANT SELECT on TABLE this_schema.my_table TO my_user
But when I login as my_user I can't select from the table. I don't want my_user to have access to any other tables in this_schema.
Is this possible?
Yes its possible.
You can use following command, to give select access of specific table to specific user.
GRANT SELECT on SCHEMA_NAME.TABLE_NAME TO USER_NAME;
NOTE: user still list and describe other tables in the given schema.
You need to grant usage on the schema as well
GRANT USAGE ON SCHEMA this_schema TO GROUP my_user;
Without creating user group, you can do:
GRANT SELECT ON TABLE my_table IN SCHEMA this_schema TO my_user;
I've added a user to a Firebird 2.1 instance using gsec, but now I wanted to grant SELECT on all tables to this new user. I could find how to grant this permission on specific tables, but not to them all:
GRANT SELECT ON TABLE table TO USER user;
If I try to use the new user I get the following error on isql:
no permission for read/select access to TABLE table
Is there a way to do that on Firebird 2.1?
Something like this:
EXECUTE BLOCK
AS
DECLARE VARIABLE tablename VARCHAR(32);
BEGIN
FOR SELECT rdb$relation_name
FROM rdb$relations
WHERE rdb$view_blr IS NULL
AND (rdb$system_flag IS NULL OR rdb$system_flag = 0)
INTO :tablename DO
BEGIN
EXECUTE STATEMENT ('GRANT SELECT ON TABLE ' || :tablename || ' TO USER TEST');
END
END
I could find how to grant this permission on specific tables, but not to them all
You can grant specific privileges to all users, already existing and yet to be created. That is made by granting privilege to "PUBLIC" pseudo-user. Or you could grant privileges to some ROLE, then grant this ROLE to given users, then during database connection specify the option, that the user impersonate this ROLE in this session.
However there is no syntax to grant privileges to all generators or all procedures or all views or all tables, etc.
See the GRANT statement syntax in documentation.
What you can do though, is creating a simple script (anonymous and volatile aka EXECUTE BLOCK or persistent and named as STORED PROCEDURE) and that script of yours would be querying system tables to list all non-system ( COALESCE(RDB$SYSTEM_FLAG,0)=0 ) tables (together with views, or tables but not views: check if RDB$RELATION_TYPE is 0 or is 0 or 1) and then form a sequence of GRANT statements and execute them one by one.
See documentation about EXECUTE BLOCK and FOR SELECT ... INTO ... DO ... and EXECUTE STATEMENT ( or maybe FOR EXECUTE STATEMENT also, but I do not think it already was there in FB 2.1. There is unofficial wiki tracking which statements were available since which FB versions, but it is not thorough and may contain errors: http://firebirdsql.su/doku.php ).
https://www.firebirdsql.org/file/documentation/reference_manuals/fblangref25-en/html/fblangref25-security-privs.html#fblangref25-security-privs-grant
https://www.firebirdsql.org/file/documentation/reference_manuals/fblangref25-en/html/fblangref-appx04-relations.html
https://www.firebirdsql.org/file/documentation/reference_manuals/fblangref25-en/html/fblangref25-psql-coding.html#fblangref25-psql-execstmt
https://www.firebirdsql.org/file/documentation/reference_manuals/fblangref25-en/html/fblangref25-dml-execblock.html