When I create a USER with "CREATE USER user1 WITH PASSWORD 'aaaaaaaa'
It is also creating a ROLE in PG_ROLES table with role name as same as 'user1'
Is it a trigger peforrming the this? Or is it default behavior?
Assuming you are not running a very old (<8.1) version of Postgresql this is explained by the documentation for CREATE USER:
CREATE USER is now an alias for CREATE ROLE. The only difference is
that when the command is spelled CREATE USER, LOGIN is assumed by
default, whereas NOLOGIN is assumed when the command is spelled CREATE
ROLE.
Further details are available in the Database Roles section of the documentation:
The concept of roles subsumes the concepts of “users” and “groups”. In
PostgreSQL versions before 8.1, users and groups were distinct kinds
of entities, but now there are only roles. Any role can act as a user,
a group, or both.
The system catalogs docs explain that:
The view pg_roles provides access to information about database roles.
So based upon this it is to be expected that running CREATE USER will have an impact on pg_roles.
Related
I was using node.js to work on snowflake datawarehouse as a destination for users. I wanted to check if a user has the required permission level on the schema to create a table and write into it before adding the user to the database otherwise it should give an error saying that the user does not have the appropriate permission level. How can I achieve that programatically?
Thanks,
one way you could do is check if the role has SEELCT privilege on the table by looking into the view TABLE_PRIVILEGES in information_schema schema.
select * from information_schema.TABLE_PRIVILEGES where table_name = 'SALES_RAW'
Due to how permissions can be inherited through the role hierarchy, this isn't easy to do. Permissions aren't assigned to users in Snowflake, they are assigned to roles. You could use the table_privileges in the information schema (as Himanshu said). You'll need to ask your admin for privileges to the information_schema schema in the databsae:
You could probably use some combination of these too:
show grants to user [username]
with
show grants on schema [schema name]
The easiest way would be to have your app / script / service assume the same role as the user and see if you can select from a table in the schema or try to create a temporary table in the schema. If you receive an error code, the user doesn't have permissions!
I have created a new user in a MaxDb database. I assign a role that has access to all the tables in roleprivileges but the user can not see these tables.
The user can access the tables if I assign permissions directly to the tables in tableprivileges.
The role has access, other users have this role assigned and they see all the tables.
What can be failing?
Today I've heard of MaxDB for the first time (what an ignoramus, eh?). I'm not sure why you tagged your question with the "Oracle" tag; Google says that MaxDB <> Oracle.
Anyway: it sounds like common problems in Oracle's PL/SQL, where privileges - acquired via roles - won't work, but have to be granted directly to the user.
Saying that "other users have this role assigned and they see all the tables", are you sure that they don't have direct privileges granted as well?
Assuming this deals indeed with MaxDB, and not with Oracle:
In contrast to privileges, roles need to be activated for a user session. Assigning is not enough. It is done by command SET ROLE <role>.
A role may also be activated as default for every new session, with command:
ALTER USER <user> DEFAULT ROLE <role>.
You can also activate all roles assigned to the user, like this:
ALTER USER <user> DEFAULT ROLE ALL.
I'm using the Oracle Database EX 11.2.0.2.0 and I hava a quite simple database created there.
Now the issue is i would like to have multiple users with different privileges set up. I have found that topic: How to create a user in Oracle 11g and grant permissions
but I cannot find anywhere the basic thing about users accounts:
what are the difference between creating system-leveled and particular database-leveled user?
I've logged in sqlplus as SYSTEM and executed the following commands:
CREATE USER TEST IDENTIFIED BY password;
GRANT CONNECT TO TEST;
and now the problem is that my databse is actually called let's say BASE with one table called PAYMENTS and to give any privileges to a newly created user I cannot execute:
GRANT SELECT ON PAYMENTS TO TEST;
but I have to type in:
GRANT SELECT ON BASE.PAYMENTS TO TEST;
so I suppose I missed something. Is it any way of connecting the created user to a particular database? So that the newly created user will be visible as a database user in Oracle APEX?
When referencing objects in other schemas, you must provide the schema name. An other user might have a table with the same name. Currently you are logged in with the system user, which is not advisable. When creating objects in the BASE schema (another name for user in de Oracle DB), why not give the user some extra rights (like granting privileges)?
The core of your problem is that you want to grant privileges to user A on object owned by B, logged in as user C. You have to be very specific in that case to Oracle what privileges are granted to whom ;)
Users and schemas are synonymous in Oracle - basically. A schema is the collection of objects owned by a user.
To get what you want, you would need to create users lacking the privs to create anything and only have the ability to select from the objects of others.
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'm trying to create a role to give a few users permission to create and alter views, procedures and tables.
I don't want these users to be able to select from/update/delete/alter etc. any table in the database, there are tables we want to keep control of - but they should have full permissions on any objects they create.
I've given the users permissions to create views etc. and that works fine, but they can't then select from views they then create. Is it possible to do this?
-- ADDED 25/july/2013
Example:
An example user Mike has specific permissions granted on a handful of tables. All Grant, no Deny.
No other database level permissions beyond "connect"
Plus is a member of public (not altered - no denys), plus 3 other roles we have set up
Role: Standard_Reader
Specific Select permissions on a number of tables. All Grant, no Deny.
No other database level permissions
Role: SensitiveDemographicsReader
Specific Select permissions on sensitive tables. All Grant, no Deny
Role: Analyst
No Specific securables
Database level permissions:
Create Function
Create Procedure
Create Table
Create View
This user can create a table or view, but once created, can't select from it.
Is it possible to set up SQL server so that whenever a user user creates a table or view they then have permissions to select from it (assuming they have permissions on underlying tables in view)
-- EDIT
After some investigation it has become apparent that for some reason in our database, ownership of objects is not acruing to their creators.
Found using this code
select so.name, su.name, so.crdate from sysobjects so join sysusers su on so.uid = su.uid
order by so.crdate
All owners, with a couple of exceptions are DBO.
I can't understand why ownership is not passing to the creators of objects. Any idea what could cause this?
Sounds like what you're using to deny them in the first place is overriding the default settings. Can you post more information on what permissions the users have?
Can't comment :(
I would comment but lack privileges; have you taken a look at MySQL table permissions? It's a rather good system.
you need to grant SELECT on the schema to user/group:
GRANT SELECT ON SCHEMA::dbo TO User/Group;