Basicly i have an java application that uses oracle as a data source. Now my application connects with a user and uses connected user's schema for table creation and etc...
Now i have a requirment that my application also should work under another schema.
So i have to alternatives.
1 - Change my table names with a prefix like
select * from other_schema.table
2 - Altering the session before running any query like
alter session set current_schema=other_schema
I am curios about is there any possibilty that alter session privilege can be revoked by dba's.
Oracle documentation says that
You do not need any privileges to perform the other operations of this statement unless otherwise indicated.
https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_2012.htm
Please note that my app user will have all privileges for other_schema.
My application will be running many envoriments.
So going with first appoach, it looks like more safe but it can take long time.
Second one is faster but seems like tricky.
Yes they do. There is a role called CONNECT. This role usually (depending on version) gives you two system privileges:
create session
alter session
when your user has only create session privilege granted directly then you can not use any alter session ... statement.
Se Oracle docs:
Addressing The CONNECT Role Change
Note that the ALTER SESSION privilege is required for setting events.
Very few database users should require the alter session privilege.
SQL> ALTER SESSION SET EVENTS ........
The alter session privilege is not required for other alter session
commands.
SQL> ALTER SESSION SET NLS_TERRITORY = FRANCE;
So it really depends on Oracle version.
The CONNECT role was changed in 10gR2. It used to have most of the permissions of RESOURCE, but these were revoked in 10gR2.
I just tried ALTER SESSION with a user that only had CREATE SESSION and much to my surprise it worked, at least in 11.2.0.4.
Related
I have a user in Oracle 19C at container level, I want to grant him the privileges to switch among multiple pluggable database through alter session set container command without granting him the sysdba/dba privilege.
Please let me know, if this is possible.
You don't need any administrative role. The SYSDBA, SYSOPER, etc are only necessary if the PDB you're trying to switch to is currently CLOSED.
Otherwise -
-- drop user C##_JEFF;
-- USER SQL
CREATE USER C##_JEFF IDENTIFIED BY "oracle" container=all
DEFAULT TABLESPACE "USERS"
TEMPORARY TABLESPACE "TEMP";
-- QUOTAS
-- ROLES
-- SYSTEM PRIVILEGES
GRANT CREATE SESSION TO C##_JEFF container=all;
GRANT SET CONTAINER to C##_JEFF container=all;
And then, since you tagged SQLDev -
In addition to the Docs of course, Oracle-Base has a nice article on this concept. I will say, it's pretty rare that you would actually want COMMON users that could switch into any PDB that were not administrator accounts. Be sure you understand what the CDB is actually for before you jump in. Most applications will have everything they need defined in the pluggable database (PDB).
I granted the CREATE SESSION privilege to a recently created database user, and I granted him the SELECT privilege on some objects for different database schemas.
I find an apps schema (SCHEMA#) in v$session that is different from the database USERNAME recently created, and I would like to understand the phenomenon.
I think that he executes alter session set current schema and I would like to know if is it possible to revoke alter session privilege in Oracle 11g.
The documentation for the alter session statement says:
To enable and disable the SQL trace facility, you must have ALTER SESSION system privilege.
To enable or disable resumable space allocation, you must have the RESUMABLE system privilege.
You do not need any privileges to perform the other operations of this statement unless otherwise indicated.
As you don't need any privileges to perform alter session set current_schema, there is nothing you can revoke to prevent that being done. If you had actually granted alter session - which you haven't, from what you said - then you could of course still revoke that, but it would make no difference to the ability to change the current schema.
But this isn't really a problem, and is mentioned in the security guide as a good thing:
For example, a given schema might own the schema objects for a specific application. If application users have the privileges to do so, then they can connect to the database using typical database user names and use the application and the corresponding objects. However, no user can connect to the database using the schema set up for the application. This configuration prevents access to the associated objects through the schema, and provides another layer of protection for schema objects. In this case, the application could issue an ALTER SESSION SET CURRENT_SCHEMA statement to connect the user to the correct application schema.
Your recently-created user does not have any additional privileges or abilities simply by changing their current schema. They have not 'become' that schema; they can still only do the things you specified by granting select privileges on objects. They can't see anything else, and can't do any more to the objects they can see. They haven't inherited any of the privileges that schema has - so they can't create or drop objects under that schema, for instance. (You would have to explicitly grant them additional any privileges, which presumably you have no intention of doing.)
What they can do is reference those objects without having to prefix them with the schema name, and without having to create synonyms. But they can still only select from them (if that is the only privilege you granted).
As per documentation changing ownership to the database by creating a role.
A role can also be the owner of a database. The "alter database" command can be used to set the owner of a database to a role.
I don`t know further steps how to proceed after changing the owner of data to a role.
I followed the below syntax to set the owner ship
ALTER (DATABASE|SCHEMA) database_name SET OWNER [USER|ROLE] user_or_role;
create role ;
Alter database first set owner xyz;
I'm using Oracle's 10g version.
In the database, I would like to create a configuration table and fill it with data.
Then the other users can not change anything in it, and even better that it was not at all visible to other users. Is it possible to somehow hide the table?
Regards
Create a separate schema for that table. Create a package that provides an API to your configuration data (e.g. to get a value that is needed by another program).
Revoke CREATE SESSION privilege from that schema (i.e. just don't grant any privileges to the schema at all). Don't grant any privileges on the table. The only users who will be able to see the table are those with DBA privileges.
The only thing that database sessions will be able to do is execute the package, IF they have been granted EXECUTE privilege on it.
If you do not grant enough privileges to other users, they could not see your objects.
I am trying to drop a tablespace in oracle 10g , using my application .
A bit about my application -- In my application I can create tablespaces.
Now what happens in oracle is that when you create a tablespace , then a new user automatically gets created and is attached to the database.
When you have to drop a tablespace what one has to do is to , first drop the user connected to the database and then the database.
When I try to drop a user associated with a tablespace.
An exception is thrown by the database which is the System.Data.OracleClient.OracleException
The details of the exception are as follows - ORA - 01904 (Can Not drop a user that is currently connected)
The thing is I have closed all the connections.Pretty sure about this.
Still oracle is throwing this exception.
Any suggestions???
Still it is not able to drop the user and throws the exception.
It can happen that you closed applications but did not ended Oracle sessions for that user. Log in as sysdba and query active sessions:
SQL> select sid, serial#, username from v$session;
SID SERIAL# USERNAME
---------- ---------- ------------------------------
122 2557 SYS
126 7878 SOME_USER
If you find your user in this list then kill all his sessions:
SQL> alter system kill session 'sid,serial#';
Seems to be your error code is ORA-01940 and not ORA-01904 which says -
ORA-01940: cannot DROP a user that is currently logged in
Cause: An attempt was made to drop a user that was currently logged in.
Action: Make sure the user is logged out, then re-execute the command.
Hope the below link might help you -
http://www.dba-oracle.com/t_ora_01940_cannot_drop_user.htm
We do following and works..
ALTER TABLESPACE "OUR_INDEX" OFFLINE NORMAL;
DROP TABLESPACE "OUR_INDEX" INCLUDING CONTENTS AND DATAFILES CASCADE CONSTRAINTS;
Please be sure that the user you're trying to drop is not currently connected. I did encounter this problem last year. My workaround was to restart the database. Once the database is up i drop the user.
Another workaround i haven't tried was to restart the listener. This too (logically) can ensure that the 'to be dropped' user is not connected when the listener is down.
This workaround (of course) cannot be used in production database.
A user does NOT automatically get created when you create a tablespace.
A user does get assigned a default tablespace. They may (or may not) create objects in that tablespace. They may (or may not) create objects in other tablespaces too.
Generally, rather than dropping the user, I would drop the user's objects. Then lock the account so they can't log in again. Then revoke any privileges they have.
If desired, you can then drop the 'unused' users after month or so.