I am using postgresql. I have created a user and grant access on db. I want user can only see granted schema objects and rest database/schema objects can't watchable. Please guide me.
You need to alter the user and set the search path.
ALTER USER foo SET search_path TO '$newschema,pg_catalog';
Note that in order to get a proper backup of globals such as this you have to use pg_dumpall -g, not pg_dump. Obviously a base backup will have them as well.
Related
Can a read-only user create the temp tables in PostgreSQL.
If not, is there any way to give access only to create temp tables.
please advice, thank you
You have to give him the "TEMPORARY" privilege:
GRANT TEMPORARY ON DATABASE {dbname} TO {role}
For a full explanation of permissions you can check the docs: https://www.postgresql.org/docs/15/sql-grant.html
we have a postgres database we want to run a number of checks against. Part of the tool involves looping over database all the database tables and views, checking grants and other things - so it would be entirely pointless if we had to grant access to this user to individual tables.
We want to be able to create a user that has full read privileges to anything, regardless of what permissions are set in the database - like a db owner - but has no write access at all.
Is this possible in any way?
The only way to do this is granting the SELECT privilege on every individual object that needs to be examined. You can make the work easier with
GRANT SELECT ON ALL TABLES/SEQUENCES/... IN SCHEMA ... TO ...;
You can also use ALTER DEFAULT PRIVILEGES to set the permissions on future objects.
I recommend that you create a readonly role and do all that once. Then you can create a read-only user by making the user a member of that role.
With postgresql 14 you can just do:
GRANT pg_read_all_data TO my_role;
https://www.postgresql.org/docs/14/predefined-roles.html
Hi: I have an interesting problem that needs a clever solution :-)
PG 9.6.5 on RHEL6_64
Constraints I have to live with:
- I'm not a superuser, but I do have createrole.
- Password is required for login
Let's say I have a table called "approvals"...
create table approvals (approval_id text);
And another table called "granters"...
create table granters (linux_uid text);
I need a perl/DBI script that must allow all users select, but only those linux_uids in the "granters" table can insert/update/delete into the "approvals" table. But when someone who is in the "granters" table runs the perl script, I do not want them to have to enter a password. The perl script can validate that an authorized user is running it using 'getlogin' and that's good enough.
I can create roles for the granters and grant them select/insert/update/delete on the "approvals" table, but they'd have to enter a password to log in first (one of the constraints on the DB is that pawwsords are required). So I can't see how this traditional method would work.
I could create before insert, update and delete triggers that can check the id of the person running the perl script against the list of uids in the "granters" table, then allow/reject the attempt on that basis. But I can't pass the linux uid into the stored procedure associated with the trigger(s). Something like perlplu might allow me to sniff out the linux uid, but again, I'm not a superuser, so (I believe) I can't create something like that.
Any ideas ?
Thanks in Advance !
Users are authenticated before any permissions inside the database are checked, so you cannot do that just within the database. Also, since you need to do something outside the database, you need superuser privileges.
First, if I were you, I'd rethink that requirement. It looks complicated and cumbersome; there should be a better solution.
You could use trust or ident authentication for password-less authentication, but you cannot make that dependent on the contents of a table in the database. It is governed by the pg_hba.conf file.
So what you'd have to do is to create a trigger on the table that runs with superuser privileges through SECURITY DEFINER and edits (and reloads!) pg_hba.conf whenever the table is modified. This is complicated, error-prone and dangerous.
I am working around a workaround to a "feature" in IBM DB2.
This fancy database has a "feature" in it which if I try to use a CREATE TABLE statement and it doesn't find the schema, it will create this schema for me, even if I don't want it to. This bug has caused me a lot of hours in debugging, because my code right now exists with the expectation that it won't create the schema if it doesn't exist
My question is -- how do I change the permissions of a particular schema (or even during the create schema phase) which a particular user does not have access to view?
I checked out this doc..
It seems with GRANT, there are the following three permissions:
ALTERIN
Grants the privilege to alter or comment on all objects in the
schema. The owner of an explicitly created schema automatically
receives ALTERIN privilege.
CREATEIN
Grants the privilege to create
objects in the schema. Other authorities or privileges required to
create the object (such as CREATETAB) are still required. The owner of
an explicitly created schema automatically receives CREATEIN
privilege. An implicitly created schema has CREATEIN privilege
automatically granted to PUBLIC.
DROPIN
Grants the privilege to drop
all objects in the schema. The owner of an explicitly created schema
automatically receives DROPIN privilege
With only ALTERIN, CREATEIN, and DROPIN, I don't see anything relevant to view access permissions :/
EDIT:
I checked out our Dash DB database for this particular table which has these special permissions for particular users using the following SQL:
SELECT * FROM SYSIBMADM.PRIVILEGES WHERE OBJECTSCHEMA = 'FAKE_SCRATCH';
This is the result:
EDIT 2:
I tried the following to emulate Dash DB's permissions for that user for that schema:
GRANT ALTERIN, CREATEIN, DROPIN ON SCHEMA FAKE_SCRATCH TO USER TEST_USER;
Still doesn't work :/
The following SQL query executed in DB2 fixed the problem:
REVOKE IMPLICIT_SCHEMA ON DATABASE FROM PUBLIC
We like our production environment with a restricted/unchangable schema -- the development side can be owned by the developers and changed as they like -- and we like to vet changes as they are promoted.
I'm wondering if this may be a solution to making that happen:
postgres% create proddb with owner=postgres;
unixside% pg_restore --dbname=devdb [--schema-only] --no-owner proddb
/* grants to users on schema objects appear to remain intact */
/* here's the magic, I hope... */
postgres% revoke create on schema public from public;
postgres% grant usage on schema public to produser(s);
Some testing seems to show that a user in this new proddb can interact with tables normally (with appropriate grants) and cannot alter the schema (alter table, create table, drop table, etc). But I'm paranoid and very new to Postgres, so...
Q: Is this correct?
Q: Am I missing anything?
Thanks muchly.
Yes, that is correct. The only addition is that the owner of a table can always delete or modify it. So it may not work if you have existing tables in the schema.
Discovered a missing element: sequences.
The user was finding errors in his scripts; similar errors appeared in the logs:
ERROR: permission denied for sequence <sequence>
The production schema showed that although sequences were created, they were owned by postgres and no explicit grants were given to the users. As per the GRANT documentation:
Granting permission on a table does not automatically extend permissions to any sequences used by the table, including sequences tied to SERIAL columns. Permissions on sequence must be set separately.
Our fix (verbose for this demonstration) was to find all sequences:
unixside% pg_dump --schema-only proddb > proddb.schema
unixside% grep -i 'create sequence' proddb.schema
...and apply appropriate grants (select to prevent table scans, update to prevent the above errors):
postgres% grant select,update on <sequence> to produser(s);
So far, the user says it's working and errors to the log have stopped...
I forget what version PostgreSQL added the syntax, but one of the easiest ways to administer permissions in PostgreSQL is through the "GRANT foo, priv ON ALL something IN SCHEMA" syntax.
BEGIN;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA my_schema TO my_role;
GRANT USAGE ON ALL SEQUENCES IN SCHEMA my_schema TO my_role;
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA my_schema TO my_role;
COMMIT;
Very handy for making sure that permissions are always set correctly.
The EXECUTE for FUNCTIONS may seem spooky, but shouldn't be unless your functions were created with the SECURITY DEFINER attribute (and if you are using SECURITY DEFINER, you'd better be cautious since you're playing around with the PostgreSQL version of a "setuid" function). If you space out your TABLES across different SCHEMAS based on the expected permissions, then this becomes a pretty handy convention when used with the search_path variable.
ALTER ROLE my_role SET search_path = my_schema, auth_schema, public;
-- Avoid using the public schema (pretty please)
Where auth_schema has a collection of tables that my_role shouldn't have direct read or write privileges on. Assigning privs to GROUPS is also useful.
Here are some relevant docs:
http://developer.postgresql.org/pgdocs/postgres/sql-grant.html
Don't forget you can use "\h GRANT" in psql to easily figure out the syntax or remember what can be done on all objects in a schema (search for "IN SCHEMA").