I have multiple databases in postgreSQL. I have created unique users with the intention of giving them access to a unique database. After creating the users, the first thing I did was use the following command:
GRANT ALL PRIVILEGES ON DATABASE dbname to username;
Then all the created users could connect to all the existing databases.
After this I tried with a new user without granting any permissions. Instead I created a new role with connect on privilege to a particular database and attached this role to the new user. But the result was same, the new user could connect to any database. I then tried revoking all privileges with the command:
REVOKE ALL ON DATABASE dbname FROM PUBLIC;
The issue remains.
Look at the permissions on the database:
SELECT datacl FROM pg_database WHERE datname = 'dbname';
If that is NULL, then the default permissions apply: the owner of the database has all privileges, and PUBLIC can CONNECT and TEMP.
In that case, your REVOKE statement would prevent username from connecting to that database, unless username is the owner of the database (or a member of the owner).
Related
I have a requirement where I need to revoke users access on a particular schema as we will be purging that schema and its table in future.
Currently, the process followed to create Schema and grant access is like below,
Create Schema
Create DB Role
Create Azure AD Group on azure portal
Create DB User with the same name as AD group
Then, we run EXEC sp_addrolemember command to add DB user to DB role in database.
Finally, we run the Grant command to give permission (Select, Insert etc) on Schema to DB Role.
Now, whenever any new user need access to that schema we simply add him in the Azure AD group and he is able to see and access that schema.
However, when I Revoke the access of user by removing him from Azure AD group he is still able to see that Schema.
As I am not an expert in SQL so I am not sure what am I missing in order to revoke his access.
I also tried Revoke command like below but still the user is able to see the schema.
REVOKE SELECT ON SCHEMA :: Schema_Name TO [DB Role]
Am I missing anything, can anyone please let me know the right steps to revoke user access so that they should not be able to see that schema anymore or should not be able to run any command on that schema not even select command?
Then, in addition to remove it from the AD group, try to deny permissions on the schema:
DENY SELECT,VIEW DEFINITION On SCHEMA::Schema_Name To [user_name]
I need to create a new firebird-db user which has only access to 4 specific tables. Is there a way to do that?
http://www.destructor.de/firebird/gsec.htm isn't really helpful in that regard.
The - third-party - gsec documentation you link does not provide information about granting rights on tables, because gsec is only for managing users in the security database. In Firebird, rights of users are managed in the individual databases using the GRANT (and REVOKE) statements (it is even possible to grant rights to users that do not exist (yet)). Be aware, Firebird 3 deprecated gsec, and since Firebird 2.5, it is recommended to use the SQL user management statements instead of gsec.
You need to create the user, and then give the user privileges to the tables you want. See the Security chapter in the Firebird 2.5 Language Reference.
A regular, authenticated user has no privileges on any database object
until they are explicitly granted, either to that individual user or
to all users bundled as the user PUBLIC.
Specifically:
Create a user:
create user <username> password '<password>';
See also CREATE USER; to create a user, you need to be either SYSDBA, or you need to have and the admin role in the security database, and the RDB$ADMIN role in the current database, and be logged in specifying the RDB$ADMIN role on connect.
Grant the necessary privileges to the user. For example to give SELECT privileges:
grant select on table <tablename> to user <username>;
To allow select, insert, update and delete:
grant select, insert, update, delete on table <tablename> to user <username>;
See also GRANT; to grant permission to an object, you must be either SYSDBA, the owner of the object, be RDB$ADMIN in the current database, or have been granted the privilege(s) with the WITH GRANT OPTION.
When you need to grant the same set of rights to multiple users, it is better to grant rights to a role, and then grant that role to the users. However in Firebird 3 and earlier, to get the rights granted to a role, the user needs to explicitly specify that role on connect (Firebird 4 will introduce roles that are automatically applied).
I have been tasked to host HTML & PHP files of a website on one virtual machine and to set up a Postgresql database on another virtual machine.
I recently installed Postgresql and have been using the official Postgresql Documentation to learn how to create databases, create user and grant & revoke rights.
After having created a database named mfc_dst, I was ordered to create 4 differents users and this is where I have a problem :
-The first user has to be named admin and must be the only other user than the pre-existing user named postgres to have unlimited rights.
-The second (named cfc) and third user (named sec) must only have the SELECT and UPDATE privileges on all tables of the mfc_dst database.
-And the fourth/last user (named prof) must only be able to view a table named devoir from the database named mfc_dst.
To accomplish this, I used 2 different scripts :
CREATEandGRANT.sql
REVOKE ALL ON ALL TABLES IN SCHEMA public TO cfc;
REVOKE ALL ON ALL TABLES IN SCHEMA public TO sec;
REVOKE ALL ON ALL TABLES IN SCHEMA public TO prof;
GRANT CONNECT ON DATABASE mfc_dst TO admin;
GRANT CONNECT ON DATABASE mfc_dst TO cfc;
GRANT CONNECT ON DATABASE mfc_dst TO sec;
GRANT CONNECT ON DATABASE mfc_dst TO prof;
GRANT SELECT,UPDATE
ON ALL TABLES IN SCHEMA public
TO cfc;
GRANT SELECT,UPDATE
ON ALL TABLES IN SCHEMA public
TO sec;
GRANT SELECT ON devoir TO prof;
and this other one :
REVOKE.sql
REVOKE ALL ON TABLE professeur FROM PUBLIC;
REVOKE ALL ON TABLE reserver FROM PUBLIC;
REVOKE ALL ON TABLE salle FROM PUBLIC;
REVOKE ALL ON TABLE semaine FROM PUBLIC;
REVOKE ALL ON TABLE surveiller FROM PUBLIC;
Thanks to these 2 scripts, I was able to prevent the user named prof from seeing other tables, but the problem I have is that the users named cfc,sec and prof are still all three able to create tables and to drop them.
Is it possible to know how to prevent them from doing this and if possible, in the future, prevent newly created users from having such rights/privileges ?
Thank you in advance
All Postgres users implicitly are also automatically members of the public role, which grants them all permissions on the public schema. You can remove permissions from the public role with
revoke all on database mfc_dst from public;
revoke all on schema public from public;
Additionally, consider defining a new schema for your data tables, so that you can issue grant statements without having to deal further with the public role. If you do this, you can also set the search path to include your custom schema and to exclude the public schema.
Also, you might want to create a group role for the cfc and sec users and assign permissions to that role, rather than to the users individually. This will make future maintenance easier.
I'm moving from MySQL to PostgreSQL and have hit a wall with user privileges. I am used to assigning a user all privileges to all tables of a database with the following command:
# MySQL
grant all privileges on mydatabase.* to 'myuser'#'localhost' identified by 'mypassword';
It appears to me that the PostgreSQL 9.x solution involves assigning privileges to a "schema", but the effort required of me to figure out exactly what SQL to issue is proving excessive. I know that a few more hours of research will yield an answer, but I think everyone moving from MySQL to PostgreSQL could benefit from having at least one page on the web that provides a simple and complete recipe. This is the only command I have ever needed to issue for users. I'd rather not have to issue a command for every new table.
I don't know what scenarios have to be handled differently in PostgreSQL, so I'll list some of the scenarios that I have typically had to handle in the past. Assume that we only mean to modify privileges to a single database that has already been created.
(1a) Not all of the tables have been created yet, or (1b) the tables have already been created.
(2a) The user has not yet been created, or (2b) the user has already been created.
(3a) Privileges have not yet been assigned to the user, or (3b) privileges were previously assigned to the user.
(4a) The user only needs to insert, update, select, and delete rows, or (4b) the user also needs to be able to create and delete tables.
I have seen answers that grant all privileges to all databases, but that's not what I want here. Please, I am looking for a simple recipe, although I wouldn't mind an explanation as well.
I don't want to grant rights to all users and all databases, as seems to be the conventional shortcut, because that approach compromises all databases when any one user is compromised. I host multiple database clients and assign each client a different login.
It looks like I also need the USAGE privilege to get the increasing values of a serial column, but I have to grant it on some sort of sequence. My problem got more complex.
Basic concept in Postgres
Roles are global objects that can access all databases in a db cluster - given the required privileges.
A cluster holds many databases, which hold many schemas. Schemas (even with the same name) in different DBs are unrelated. Granting privileges for a schema only applies to this particular schema in the current DB (the current DB at the time of granting).
Every database starts with a schema public by default. That's a convention, and many settings start with it. Other than that, the schema public is just a schema like any other.
Coming from MySQL, you may want to start with a single schema public, effectively ignoring the schema layer completely. I am using dozens of schema per database regularly.
Schemas are a bit (but not completely) like directories in the file system.
Once you make use of multiple schemas, be sure to understand search_path setting:
How does the search_path influence identifier resolution and the "current schema"
Default privileges
Per documentation on GRANT:
PostgreSQL grants default privileges on some types of objects to
PUBLIC. No privileges are granted to PUBLIC by default on tables,
columns, schemas or tablespaces. For other types, the default
privileges granted to PUBLIC are as follows: CONNECT and CREATE TEMP TABLE
for databases; EXECUTE privilege for functions; and USAGE privilege for languages.
All of these defaults can be changed with ALTER DEFAULT PRIVILEGES:
Grant all on a specific schema in the db to a group role in PostgreSQL
Group role
Like #Craig commented, it's best to GRANT privileges to a group role and then make a specific user member of that role (GRANT the group role to the user role). This way it is simpler to deal out and revoke bundles of privileges needed for certain tasks.
A group role is just another role without login. Add a login to transform it into a user role. More:
Why did PostgreSQL merge users and groups into roles?
Predefined roles
Update: Postgres 14 or later adds the new predefined roles (formally "default roles") pg_read_all_data and pg_write_all_data to simplify some of the below. See:
Grant access to all tables of a database
Recipe
Say, we have a new database mydb, a group mygrp, and a user myusr ...
While connected to the database in question as superuser (postgres for instance):
REVOKE ALL ON DATABASE mydb FROM public; -- shut out the general public
GRANT CONNECT ON DATABASE mydb TO mygrp; -- since we revoked from public
GRANT USAGE ON SCHEMA public TO mygrp;
To assign "a user all privileges to all tables" like you wrote (I might be more restrictive):
GRANT ALL ON ALL TABLES IN SCHEMA public TO mygrp;
GRANT ALL ON ALL SEQUENCES IN SCHEMA public TO mygrp; -- don't forget those
To set default privileges for future objects, run for every role that creates objects in this schema:
ALTER DEFAULT PRIVILEGES FOR ROLE myusr IN SCHEMA public
GRANT ALL ON TABLES TO mygrp;
ALTER DEFAULT PRIVILEGES FOR ROLE myusr IN SCHEMA public
GRANT ALL ON SEQUENCES TO mygrp;
-- more roles?
Now, grant the group to the user:
GRANT mygrp TO myusr;
Related answer:
PostgreSQL - DB user should only be allowed to call functions
Alternative (non-standard) setting
Coming from MySQL, and since you want to keep privileges on databases separated, you might like this non-standard setting db_user_namespace. Per documentation:
This parameter enables per-database user names. It is off by default.
Read the manual carefully. I don't use this setting. It does not void the above.
Maybe you could give me an example that grants a specific user
select/insert/update/delete on all tables -- those existing and not
yet created -- of a specific database?
What you call a database in MySQL more closely resembles a PostgreSQL schema than a PostgreSQL database.
Connect to database "test" as a superuser. Here that's
$ psql -U postgres test
Change the default privileges for the existing user "tester".
ALTER DEFAULT PRIVILEGES IN SCHEMA public
GRANT INSERT, SELECT, UPDATE, DELETE ON TABLES
TO tester;
Changing default privileges has no effect on existing tables. That's by design. For existing tables, use standard GRANT and REVOKE syntax.
You can't assign privileges for a user that doesn't exist.
You can forget about the schema if you only use PUBLIC.
Then you do something like this: (see doc here)
GRANT { { SELECT | INSERT | UPDATE | DELETE | TRUNCATE | REFERENCES | TRIGGER }
[, ...] | ALL [ PRIVILEGES ] }
ON { [ TABLE ] table_name [, ...]
| ALL TABLES IN SCHEMA schema_name [, ...] }
TO { [ GROUP ] role_name | PUBLIC } [, ...] [ WITH GRANT OPTION ]
I don't want to grant rights to all users and all databases, as seems to be the conventional shortcut, because that approach compromises all databases when any one user is compromised. I host multiple database clients and assign each client a different login.
OK. When you assign tables to the correct role, the privileges granted will be role-specific and not to all users! Then you can decide who to give roles to.
Create a role for each database. A role can hold many users.
Then assign a client-username to the correct role.
Also assign your-username to each role if needed.
(1a) Not all of the tables have been created yet, or (1b) the tables have already been created.
OK. You can create tables later.
When you are ready, assign tables to the correct client role.
CREATE TABLE tablename();
CREATE ROLE rolename;
ALTER TABLE tablename OWNER TO rolename;
(2a) The user has not yet been created, or (2b) the user has already been created.
OK. Create usernames when you are ready. If your client needs more than one username simply create a second client-username.
CREATE USER username1;
CREATE USER username2;
(3a) Privileges have not yet been assigned to the user, or (3b) privileges were previously assigned to the user.
OK. When you are ready to give privileges, create the user and assign the correct role to her.
Use GRANT-TO command to assign roles to users.
GRANT rolename TO username1;
GRANT rolename TO username2;
(4a) The user only needs to insert, update, select, and delete rows, or (4b) the user also needs to be able to create and delete tables.
OK. You run these commands to add permissions to your users.
GRANT SELECT, UPDATE, INSERT, DELETE ON dbname TO role-or-user-name;
ALTER USER username1 CREATEDB;
I have created one user named "tuser" with create database rights in SQL server 2005.
and given the 'db_owner' database role of master and msdb database to "tuser".
From this user login when I run the script for create database then it will create new database.
But "tuser" don't have access that newly created database generated from script.
Any one have any idea?, I want to write the script so "tuser" have access that new created database after creation and can have add user permission of newly created database.
I want to give 'db_owner' database roles to "tuser" on that newly created database in the same script which create new database. The script run under 'tuser'.
Grant securityadmin server role to [tuser]
Members of the securityadmin fixed
server role manage logins and their
properties. They can GRANT, DENY, and
REVOKE server-level permissions. They
can also GRANT, DENY, and REVOKE
database-level permissions.
Additionally, they can reset passwords
for SQL Server logins.
CREATE DATABASE says
Each database has an owner that can
perform special activities in the
database. The owner is the user that
creates the database. The database
owner can be changed by using
sp_changedbowner (Transact-SQL).
So tuser should own the DB already.
However, you could set up tuser as db_owner in the model db which used as the template for every db creation
BTW, why make tuser the owner of master and msdb?
If tuser doesn't have access to the new database it means is not the owner. The database owner cannot be denied access into his/her own database.
How does the CREATE DATABASE statement look like? Do you have any AUTHORIZATION clause that would change the database ownership of the new database?
Who is the actual owner of the new database? Check SELECT name, SUSER_SNAME(owner_sid) FROM sys.databases;
Thanks for your input.
i have given access of tuser to database from ehich the new database created.
now the issue is resolved.
Many thanks.