I have an oracle graphics application that works with a 10G database, however with a 11G DB it doesnt as it refuses to see some tables in the DB, i think it has to do with privelages and roles. Does anyone know how to grant roles in the graphics program. I was thinking that at in the OPEN TRIGGER i can grant the tables to public , eg: GRANT ALTER, DELETE, INDEX, INSERT, REFERENCES, SELECT, UPDATE ON GENDBA.SUPLOCATIONS TO PUBLIC; and in the close trigger i can revoke the grant therby retaining the security of the DB tables.
Can anyone out there help me?
thanks tbone. what we have done is gotten scripts to block access to the database from toad , sqtools etc and all similar programs so users wouldnt be able to access the database (only given them forms access) and removed the passwords from all the tables. well something like that and the graphics seem to work. Thanks guys
Related
Is there a way to grant privileges of select, insert, update and delete to a user so that if we add a new table later, the user still have these privileges on the new table ?
Thanks for help,
The quickest and dirtiest way to go about something like this is to create a trigger on all create table statements in the DB, and then granting privileges on tables fitting your pre-defined conditions.
However, I don't see why not to add a grant command to every create table command ran in the system.
Bear in mind that DDLs and grant commands are not something to be taken lightly. Designing your schema and its privileges should be done with careful thought, and automating is a recipe for problems further down the road.
Although not a recommended practice for security reasons on a development instance this is acceptable
grant select, insert, update, delete any table to your_user;
I stress again that this allows that user access to any table in any schema except SYS and is not a best practice.
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.
For our application we're using outsorced Oracle administration. Now we'd like to prevent external oracle administrator from changing our data (DELETE, INSERT, UPDATE).
Is there any way how to do it?
Is there possible to REVOKE eg. UPDATE ANY TABLE to SYS account and is this sufficient?
I have read the Oracle Security Guide but haven't found anything. Only a statement: Do not use a DBA role which contains eg. the UPDATE ANY TABLE privilege.
I see I also should REVOKE GRANT ANY PRIVILEGE ...
Simply I'd need a complex guide how to do it and I'm not able to find any document about it.
Thanks
As security tightening exercise, I'm removing all system privileges from an oracle database user. Now this user ONLY has the following system privileges:
CREATE SESSION
UNLIMITED TABLESPACE
I was hoping that the user wont be able to do any DDL commands. But to my surprise, user can DROP TABLE in its own schema even though it can't create one.
Oracle documentation says prerequisite for DROP TABLE is "The table must be in your own schema or you must have the DROP ANY TABLE system privilege". Just that!!! I don't understand the security logic of Oracle but is there any way I can prevent Users from dropping their own tables?
The alternative would be creating another user to run the application and grant object access, which I'd rather like to avoid as there are potential issues.
A user will always have permissions to drop objects that they own. You can't prevent that by revoking privileges.
Since you're looking at tightening security, creating a new user and granting that user whatever privileges they need to manipulate the data is the right answer. The only people that ought to be logging in to a production database as a user that owns application objects are DBAs and then only when they are in the process of deploying changes to the schema. Everyone else should be logging in to the database as users other than the schema owner.
That being said, if the right solution is more work than you're prepared to undertake right now, a potential stopgap would be to create a DDL trigger on the database that throws an exception if a DROP is issued against an object in the specified schema. This is less secure than the proper solution. You may miss something when implementing the trigger, you or someone else may drop or disable the trigger and forget to re-enable it, etc. And it makes security reporting much more difficult because you've got a custom solution that isn't going to be obvious in the various security related data dictionary views which may create problems for auditors.
I'm not a DBA, but I have some basic understanding about how SQL Server is supposed to work. I'm having trouble translating this knowledge into getting a working Oracle XE database, so my girlfriend can play around with her bookstore coursework.
So, I installed Oracle XE database, and downloaded Oracle SQL Developer. I supplied a password, during installation, and using this password in conjunction with sys login in sysdba-mode, I'm able to connect and browse the database, which I can only assume is the master database, since there are numerous tables that have nothing to do with future bookstores.
I want to create a new - empty database, and I don't much care about how it's configured. It's a playpen for coursework. So I happily stab with:
create database bookstore
and recieve an error to the effect of:
ORA-01100: database already mounted
I just want to create a new database, so that if something goes wrong i can do a drop database bookstore instead of manually deleting tables and such. In SQL Server Management Studio you execute these statements on the master database, and then connect to the specific database you want to play with.
A SQL Server database is roughly equivalent to a schema in Oracle. And a schema in Oracle is a collection of objects owned by a particular user.
Given that, it appears that you want to do something like
Create a user
CREATE USER bookstore IDENTIFIED BY bookstore;
Grant privileges to the user
GRANT CREATE SESSION TO bookstore;
GRANT UNLIMITED TABLESPACE TO bookstore;
GRANT CREATE TABLE TO bookstore;
GRANT CREATE VIEW TO bookstore;
GRANT CREATE TYPE TO bookstore;
GRANT CREATE SYNONYM TO bookstore;
GRANT CREATE PROCEDURE TO bookstore;
GRANT CREATE SEQUENCE TO bookstore;
GRANT CREATE MATERIALIZED VIEW TO bookstore;
Now, you should be able to connect to the bookstore schema in the XE database and create whatever tables, views, triggers, etc. you want.
You just need to create a schema in the database you already have. A schema in Oracle is sort of roughly equivalent to database in SQL Server, in some ways. Your girlfriend would use that schema as her playpen and you could drop it and recreate it easily. You should also create a user for her, which I think automatically creates a schema with same name as the user. But I would still create a dedicated coursework schema.
Oracle has extensive online documentation. Here's the master index for 10g. It's a bit daunting but you'll get to know your way around it.