SELECT
D.OS_USERNAME
,D.terminal AS MACHINE
,D.OBJ_NAME
,D.ACTION_NAME
,D.timestamp
,D.Sql_Text
FROM DBA_AUDIT_TRAIL D
WHERE D.OWNER = 'HRADMIN'
AND D.ACTION_NAME LIKE '%INSERT%'
AND D.OS_USERNAME NOT IN ('MuhammadJav','zeeshankh1');
this query give me record
I want to apply limit or restriction so that only D.OS_USERNAME ('MuhammadJav','zeeshankh1','Alikh1') can run insert,update,delete,alter statements but other user can't insert,update,delete,alter the data.
In Oracle, the privilege to insert, update or delete are managed on the user or role level. Those users are database users, just like your HRADMIN.
If the operating systems users like MuhammadJav, zeeshankh1, Alikh1 use the same oracle account, things become much more difficult.
DML statements like 'ALTER' or 'CREATE' are handled totally different. A user like 'HRADMIN' can do what he/she wants with the tables and other objects in it's own schema. It is possible, but very difficult to prevent this.
So, the traditional solution is to give MuhammadJav, zeeshankh1, Alikh1 their own oracle accounts and grant them the privileges you want as user HRADMIN:
GRANT INSERT,UPDATE,DELETE ON HRADMIN.your_table_name TO MUHAMMADJAV;
GRANT INSERT,UPDATE,DELETE ON HRADMIN.your_table_name TO ZEESHANKH1;
etc
Related
Is there any way for me to see which DDL privileges I have in my own schema? I'm looking for a SELECT-type sentence.
I mean, how do I know if I can create, drop, alter, &c.?
Modification - 2019/Oct/24th - I think it would be simpler to understand "How can I know if I have the CREATE ANY TRIGGER privilege?".
Thanks in advance.
You should automagically have select privileges on tables in your own schema - they belong to you. You can figure out if you can create, drop, or alter objects based on the roles that have been granted to you. You can use a query like SELECT * FROM USER_ROLE_PRIVS; or select dbms_metadata.get_granted_ddl('ROLE_GRANT', user) from dual; to get a list of the roles that have been granted to you, and based on that, you'll know what kind of privileges you have within the database.
For example, if you see that you've been granted the "Resource" role, you will be able to do things like create tables, procedures, triggers, etc.
You can use a query like select * from session_privs; to see EVERY privilege that you have, but that will include privileges for the entire database, including privileges that are associated with a role. To see privileges that aren't associated with a role, you could use a query like SELECT * FROM USER_SYS_PRIVS;
you can get it with query on DBA_SYS_PRIVS, DBA_TAB_PRIVS, and DBA_ROLE_PRIVS to get information about user privileges about system, tables, and roles.
for example SELECT * FROM DBA_SYS_PRIVS;
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 am in the process of configuring database users for some new developers and I am running into some difficulties as I am reading lots of articles and it's not working out too well for me. I have tried various configurations manually and with T-SQL but I need a more efficient method.
My objective:
Some TSQL I can launch to give a database user the following permissions:
Grant permission to execute all Stored Procedures within the Database
Deny permission to View Definition of all of these stored procedures
Grant permission to SELECT, UPDATE, INSERT, DELETE from all tables within the database
Deny permission to View Definition of all of the tables in the database (I don't want them to view the data)
What I have tried:
I have achieved this manually but I have 200+ stored procedures and 100+ tables so I don't want to do it manually. From the T-SQL aspect I have managed to get the following to work:
USE database_name;
GRANT EXECUTE TO [security_account];
This works and allows the users to run the stored procedures but they cannot view the actual query code. I need the same logic for the tables as described above.
Thank you for your help.
I am not quite sure if this is a viable solution to your problem. But maybe it will get you at least closer to what you want. So, here is the setup I'd propose:
Do not grant anybody any permissions on any table.
Use stored procedures for DML.
Grant execute on all these stored procedures to public.
Setup one table in your database which lists all users which have access to your database including their login (suser_sname()) and their permissions (for example MayAlterTableUsers).
Implement into all stored procedures a check similar to this
if (
select isnull(MayAlterTableUsers, 0)
from tblUsers
where LoginName = suser_sname()
) > 0
begin
select N'Implementing the requested changes to tblUsers.'
end
else
begin
select N'You don''t have the required permission.'
end
Setup you views similar and grant select on all views to public
create view vShowAllUsers as
select *
from dbo.tblUsers
cross apply (
select MaySeeAllUsers
from dbo.tblUsers
where LoginName = suser_sname()
) as p
where p.MaySeeAllUsers = 1
In the end all views and all stored procedures will be publicly available but the handling of permission will be within each one of them. All permissions themselves will be within this table tblUsers. Since nobody has the possibility to alter this table tblUsers unless (of course) they are in this table with the appropriate permission, this DB setup is self-contained.
Is it possible to hide the existence of and access to databases (incl. their schemas, tables etc) from certain users within Amazon Redshift.
By default, it seems like every user is able to see other DBs even though he doesnt have permission to select data nor any other (non-default) privileges.
I tried
REVOKE ALL PRIVILEGES ON DATABASE testdb FROM testdbuser;
and similar but still testdbuser can connect to the testdb DB and even see all other objects in his object browser in a SQL tool (here: Aginity Redshift Workbench).
Ideally, testdbuser would not be able to see anything else except what he got explicitly granted access to.
Note, testdbuser is not a superuser.
Thanks!
Try to revoke from the PUBLIC group vs the specific user
REVOKE USAGE ON SCHEMA information_schema FROM PUBLIC;
REVOKE USAGE ON SCHEMA pg_catalog FROM PUBLIC; -- This should suffice, but...
REVOKE SELECT ON TABLE pg_catalog.pg_database FROM PUBLIC; -- just to be sure.
Note that this could have an undesirable effect on all users within the selected database.
You will need to do this on all databases, since the user can guess another database name and see pg_catalog information there.
The user could still find all the databases via a brute force attack simply by trying to switch or connect to all possible strings.
Unfortunately it is not possible today. Redshift does not support the REVOKE CONNECT FROM DATABASE command, so users can connect to any database.
Because Redshift is built on PostgreSQL, once connected, users can read a list of all databases in the cluster from the system tables, and by connecting to each database can read the list of schemas, tables, and even table columns from the system tables, even if they are prevented from reading the data within those tables through the use of REVOKE ... FROM SCHEMA or REVOKE ... FROM TABLE.
I have a database (SQL Server) that is being used by 20 users, all members of the same security role. The role enables them to insert, delete and update to Table1, but they have no permissions for Table2.
Table1 has a trigger that fires a stored procedure, Table2_Refresh, that truncates Table2 and rebuilds it from Table1.
I have read in some places that the trigger and stored procedure automatically execute as the caller, and therefore uses the caller's permissions. However 19 of the 20 users are able to update Table1 and the trigger and SP execute fine. One user gets an error telling him that Table2 cannot be found.
I know I can put an 'EXECUTE AS' line in the SQL, but this is happening in multiple places, and it seems like it is an issue with the user, so I would like to solve it there if possible. Since the role memberships and permissions are identical, are there any other reasons why two users would be experiencing different behaviour from the database?
The role and permissions are clearly not identical...
Are they logging in the same way (e.g. are they all using Integrated Security)?
I suggest to check the default schema of the database user used by that special login.
If the table schema is dba but the default schema of the database user is dbo, querying the table without specifying the schema will fail.