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.
Related
I'm trying to retrieve the CREATE table statement for multiple tables from oracle SQL Developer so I can run it in SQL Management to create new tables.
However, when highlighting multiple tables and right clicking > Quick DLL> Save to File, my file looks like this:
GRANT INSERT ON "OPSR"."BOOTH" TO "OPSWEB";
GRANT UPDATE ON "OPSR"."BOOTH" TO "OPSWEB";
GRANT SELECT ON "OPSR"."BOOTH" TO "OPSWEB";
GRANT DELETE ON "OPSR"."CAAR_BOOTH" TO "OPSWEB";
GRANT INSERT ON "OPSR"."CAAR_BOOTH" TO "OPSWEB";
GRANT SELECT ON "OPSR"."CAAR_BOOTH" TO "OPSWEB";
GRANT UPDATE ON "OPSR"."CAAR_BOOTH" TO "OPSWEB";
Why is there no CREATE table statements in here?
I'm connected as Opsweb and the only tables I can see are under the OPSR user.
You can't see the create DDL for other user's objects. SQL Developer is using dbms_metadata in the background, and from the documentation:
The object views of the Oracle metadata model implement security as follows:
Nonprivileged users can see the metadata of only their own objects.
Nonprivileged users can also retrieve public synonyms, system privileges granted to them, and object privileges granted to them or by them to others. This also includes privileges granted to PUBLIC.
If callers request objects they are not privileged to retrieve, no exception is raised; the object is simply not retrieved.
If nonprivileged users are granted some form of access to an object in someone else's schema, they will be able to retrieve the grant specification through the Metadata API, but not the object's actual metadata.
and so on. As the last bullet above says, you cen get the grants - which is what you are seeing now - but not the actual metadata.
If your user was granted the select_catalog_role you would be able to get the DDL for OPSR's objects, but you'd have to ask your DBA for that and it would probably be easier to connect as that user, or ask someone else who can to do that to perform the extract for you.
I have two schema "OWNER" and "USER".
I've created job in "OWNER" schema in PROD and we don't have access to login into this schema. Now I want to find a way to access these jobs in "USER" schema.
Below are the methods, I tried and did not work for me:
1)I created view in "OWNER" schema (create view test_view as select * from all_scheduler_jobs) and gave a grant "GRANT SELECT OWNER.test_view to USER". But still I did not find any records in USER schema.
2)Created a view as mentioned above and after that I created synonym in USER schema( create synonym USER.test_view for OWNER.test_view.
Please let me know if there is anything that I'm missing or is there any other way that I can implement.
The ALL_SCHEDULER_JOBS view only lets you see jobs to which you already have access - essentially just your own. To see properties or output from scheduler jobs belonging to other schemas, USER must have the SELECT ANY DICTIONARY privilege, which would allow access to the DBA_SCHEDULER_JOBS view. Check with your DBA to see if you are allowed to have that privilege (it opens up access to a lot of other things, too), or if they would prefer that you have a custom role that just grants access to the various DBA_SCHEDULER_% views. Note that these views would expose all jobs for all users, not just your OWNER schema; there isn't really a way to fine-tune that.
If USER needs to execute the job in another schema, then it will need the EXECUTE ANY JOB privilege, which would allow it to run any job in any schema. There's no way to make that more fine-grained at this time, either.
You can try below SQL.
SCHEMA: OWNER
commit;
SCHEMA: USER
select * from OWNER.test_view;
I would like to know how the privilege SELECT ANY TABLE works internally in Oracle.
Is it treated as a single privilege? Or is it equivalent to make a GRANT SELECT ON MyTable TO MyUser for each table?
As example, I would like to know if this work :
GRANT SELECT ANY TABLE TO PUBLIC;
REVOKE ALL ON MY_TABLE FROM PUBLIC;
Would I still have access to MY_TABLE from any user after those queries?
Yes, all users would still be able to query MY_TABLE.
You are looking at different privilege types:
The main types of user privileges are as follows:
System privileges—A system privilege gives a user the ability to perform a particular action, or to perform an action on any schema objects of a particular type. For example, the system privilege CREATE TABLE permits a user to create tables in the schema associated with that user, and the system privilege CREATE USER permits a user to create database users.
Object privileges—An objectprivilege gives a user the ability to perform a particular action on a specific schema object. Different object privileges are available for different types of schema objects. The privilege to select rows from the EMPLOYEES table or to delete rows from the DEPARTMENTS table are examples of object privileges.
SELECT ANY TABLE is a system privilege that allows the grantee to:
Query tables, views, or materialized views in any schema except SYS. Obtain row locks using a SELECT ... FOR UPDATE.
When you grant that it is a standalone single privilege, visible in dba_sys_privs. When Oracle decides if the user is allowed to access a table it can look first at system privleges, and only goes on to look for specific object privileges (visible in dba_tab_privs) if there isn't a system privilege that allows the action being performed.
System privileges are not translated into individual privileges on each object in the database - maintaining that would be horrible, as creating a new object would have to automatically figure out who should be granted privileges on it based on the system privilege; and it would mean that you couldn't tell the difference between that and individually granted privileges. So, for instance, if you explicitly granted select privs on a specific table, then the user was granted SELECT ANY TABLE, and then they had SELECT ANY TABLE revoked - what happens to the previous explicit grant?
Your scenario is basically the same, except you've specifed all privileges on the object to be revoked. If those are the only two commands involved then PUBLIC has no explicit privileges on MY_TABLE so revoking doesn't really do anything; but if any explicit privileges on that table had been granted then they would be revoked. That has no impact on the higher-level SELECT ANY TABLE system privileg though.
Privileges are cummulative; revoking a privilege on a specific object doesn't block access to that object, it just removes one possible access route.
Incidentally, hopefully you've used a contrived example, as such powerful system privileges should be granted sparingly and only when really needed. Letting any user query any table in your database potentially blows a big hole in the security model. Again from the docs:
Oracle recommends that you only grant the ANY privileges to trusted users
and
Oracle recommends against granting system privileges to PUBLIC.
and read more in the database security guide.
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 better understand why one of our database update scripts failed to work properly at a particular customer site, and narrowed it down (I think) to database ownership and roles.
Disclaimer: I'm actually waiting to hear back from the customer's DBA so they can tell us if they upgraded their SQL database recently and so we can look at their database. I'm thinking a SQL 2000 to SQL 2005 conversion might have hosed our scripts if our applications's database login was converted to a schema, because we were referencing dbo in a few places in the update script.
Anyway, I've been trying to find a better explanation of database ownership and roles and how it impacts what owner a database object is actually assigned when you don't explicitly specify the owner in a T-SQL statement. For example, our update scripts typically just do CREATE TABLE foo instead of CREATE TABLE dbo.foo or something else, but I found a few that were explicitly using dbo, and those are the ones causing problems at the moment (only for this one customer).
I found this article (specific to SQL Server 2000), but the table on that page is confusing. It mentions db_owner and "owns the database" as two distinct possibilities for what role a user can have.
For example, the table states that if a user sam, who is in the db_owner role, runs the query CREATE TABLE [test3](abc int), it will be owned by sam.
It then mentions that if a another user sue, who "owns the database" (sic), runs the same query, it will be owned by dbo.
Wouldn't db_owner and "owns the database" be the same thing? The table implies that there is a difference between "being in the db_owner role" and actually "being the owner of the database." But, if that's, true, what does it mean to "own the database" if it's something other than being a member of the db_owner role?
No, db_owner and the owner of the database are not the same. dbo is a user and db_owner is a database role. Databases are owned by logins. Whatever login owns the database is aliased as dbo inside the database. You can change the database owner by using the sp_changedbowner system stored procedure.
All objects in a database are owned by a user. Users that are members of the db_owner role, among other permissions, are allowed to create objects owned by dbo. If a user is not a member of db_owner, but has some create permissions (e.g. Create Table), then any objects they create will be owned by the user that created them. You can change the ownership of an object using sp_changeobjectowner system stored procedure.