Oracle 12c Grant Privileges Failing - oracle

I'm currently trying to grant a couple of simple privileges to an Oracle database user.
I have tried the following queries:
grant all privileges to <username>
grant alter session to <username>
The second privilege is the one I actually need, but I decided simply to try and give the user all privileges to see if that would work. When I check the user's permissions using
select * from user_sys_privs;
everything seems to say NO.
I've even tried to grant the user dba privileges and that still fails. My end goal is to run scripts that require these permissions to be turned on.
Any help is greatly appreciated.

everything seems to say NO
You're looking at the wrong thing. If the user_sys_privs view lists ALTER SESSION:
select * from user_sys_privs where privilege = 'ALTER SESSION';
USERNAME PRIVILEGE ADM COM
-------------------- ------------- --- ---
MY_USER ALTER SESSION NO NO
then the user does have that privilege.
The NO entries don't mean the privilege is not granted. The columns that is showing you are:
desc user_sys_privs
Name Null? Type
----------------------------------------------------------------- -------- --------------------------------------------
USERNAME VARCHAR2(128)
PRIVILEGE VARCHAR2(40)
ADMIN_OPTION VARCHAR2(3)
COMMON VARCHAR2(3)
and they are described in the documentation:
ADMIN_OPTION - Indicates whether the grant was with the ADMIN option (YES) or not (NO)
COMMON - Indicates how the grant was made. Possible values:
YES if the privilege was granted commonly (CONTAINER=ALL was used)
NO if the privilege was granted locally (CONTAINER=ALL was not used)
As you didn't specify the admin option or any other modifiers, it's correct that both of those flags are set to NO.
What's probably confusing you is that all privileges are listed when you query for your user, because you did grant all privileges to <username>. You probably want to revoke all of those privileges, and only grant the specific ones the user actually needs. You'll then see a much shorter list when you query user_sys_privs - possibly only that single entry, depending on what else you need to retain for the user.
You might also want to consider using roles, though you sometimes need to have privileges granted directly anyway - if a stored procedure relies on them.

Related

Is it possible to see a sequence in all_sequences without having the SELECT right on the sequence?

I need to retrieve the list of available sequences of a certain database schema in an Oracle 10g database (10.2.0.3).
With the schema owner, I can simply do something like the following to achieve this:
SELECT sequence_name FROM all_sequences WHERE sequence_owner = 'ABCDEF';
However, If I use a user which has a custom "read-only" role assigned, that user does not get any rows when executing that query.
I've played around a bit and found out that granting the SELECT option on the sequences to the read-only role makes those sequences appear in the all_sequences view when connected with the read-only user.
However this means that the read-only user is able to do
SELECT my_sequence.NEXTVAL FROM DUAL;
which is a no-go for our situation (after all, the read-only user shall not be able to modify anything, not even sequences).
Is there another way for retrieving the sequences which does not allow selecting NEXTVAL?
[Edit:]
If I do
SELECT DISTINCT sequence_owner FROM all_sequences;
I get the following list:
SEQUENCE_OWNER
------------------------------
MDSYS
DMSYS
OLAPSYS
XDB
SYS
5 rows selected
After using the system user to do
GRANT SELECT ANY DICTIONARY TO MY_USER;
the result stays the same (revoke does not change anything either).
Granting the SELECT_CATALOG_ROLE instead does not work either.
Granting SELECT on at least one of the sequences however changes the result to include my own schema owner.
You can try to grant SELECT ANY DICTIONARY privilege, but it's very bad for the security reasons, so, I guess, your DBA will deny it.
Good decision is to create table function publishes required data. By default this function will work with AUTHID DEFINER rights, so you should just grant it to read-only user and it would receive sequences info without any chance to change them.
The best solution I can come up with is to grant the user SELECT ANY DICTIONARY. This will give them access to DBA_SEQUENCES (as well as all of the other DBA_ views) without needing permissions on the objects.

grant update on table in different scheme

I have 3 schema's in my database:
Colldesk - Main account
Local_it - Local account for developments
User - User account
Now I am writing a procedure to grant people access based on their job. Depending on their job, they need select, or select, update, insert and delete privileges on certain tables.
I know that usually you create roles for this, but I can't (DBA's are external, and they don't like roles.......)
When running the procure, I am inserting the new user, and which department they belong to. If the department is IT_SUPPORT for example, they will need to be able to update tables in the account account and the local_it account. My procedure is located in the local_it account.
Now, when I am trying to run a script like:
for x in (select *
from all_objects
where owner in ('COLLDESK','LOCAL_IT')
and object_type in ('TABLE','VIEW')
and object_name not in ('IFM_letter_data','IFM_letter_data_V2')
order by owner asc)
loop
execute immediate 'grant update on ' || x.owner || '.' || x.object_name || ' to ' || v_user;
end loop;
I am getting an error, saying that I have insufficient privileges. Is it possible to grant update privileges on a table in a different schema? I am able to grant select privileges.
Thanks a lot in advance
Look at this: You have a friend that you trust and you gave him a key to your appartment.
Are you OK if your friend will give a copy of your key to his friend?
It might be NO, it might be YES.
When you want to grant permissions to a user you may say that it is OK for that user to share access with the others.
So, in your case:
User with tables should grant you access to her tables, with permissions to share:
grant update on my_table to you with grant option
Then you can manage access to that table.

How can I ensure a grant has been performed?

In Oracle, when I run:
GRANT SELECT on MYSCHEMA.ORDERS to APP_USER;
What query can I run in Oracle to check if this grant exists? I would like to validate that this grant is correctly created in our development, QA, and production databases.
You can get that from the all_tab_privs performance view, or the user_ or dba_ equivalents depending on your situation and privileges:
select *
from all_tab_privs
where table_schema = 'MYSCHEMA'
and table_name = 'ORDERS'
and grantee = 'APP_USER';
To see everyone who has access, leave off the grantee filter. Note though that the grantee may be (and quite probably should be) a role, not an individual user. In that case you'd need to see who has that role granted to get the full picture, and roles can be granted to roles, so that can get a bit recursive.
Execute the following (if you are logged in as app_user) :-
select owner from user_tab_privs where table_name='Order' and grantee='App_user' and owner='MySchema';
If you are logged in as dba, then execute following :-
select owner from dba_tab_privs where table_name='Order' and grantee='App_user' and owner='MySchema';
If the grant was successful, then the above sql statements should have non-null output.

Bypass "table or view does not exist" in package compilation

There are two schemas in a Oracle database.
MYSCHEMA that is controlled by me.
OTHERSCHEMA that is not controlled by me.
I just know I can get result from select * from OTHERSCHEMA.OTHEROBJECT. However, OTHEROBJECT is a synonym.
In my package, I have a statement like
insert into MYSCHEMA.MYTABLE(COL1) select COL1 from OTHERSCHEMA.OTHEROBJECT;
But it gave me Table or view does not exist.
How can I solve or bypass this problem? Thanks!
I assume you received the privilege to select from otherschema.otherobject by means of a role as opposted to a direct grant (such as grant all on otherschema.otherobject to myschema). If this is the case, the privileges within this role will not be used to determine what rights you have within a PL/SQL block.
See also How Roles Work in PL/SQL Blocks (Oracle Docu, where it says under Roles Used in Named Blocks with Definer's Rights:
All roles are disabled in any named PL/SQL block (stored procedure, function, or trigger) that executes with definer's rights. Roles are not used for privilege checking and you cannot set roles within a definer's rights procedure.)

oracle identifier 'ctx_ddl' must be declared - adding a dbms_job

I've added an index to my table with the command:
CREATE INDEX patient_index ON radiology_record(patient_name) INDEXTYPE IS CTXSYS.CONTEXT;
And I'm trying to add a DBMS_JOB which will keep it up to date.
The way I've been running this script is by calling "#myscript.sql" from SQLPLUS
set serveroutput on
declare
job number;
begin
dbms_job.submit(job, 'ctx_ddl.sync_index(''patient_index'');',
interval=>'SYSDATE+1/1440');
commit;
dbms_output.put_line('job '||job||'has been submitted.');
end;
/
The resulting error is PLS-00201: identifier 'CTX_DDL' must be declared
Through my searching I've found someone with a similar problem and his solution was
I spent enough time
debugging this that I thought it
merited sharing what i learned. It
turns out that dbms_jobs only inherit
your schema user's default privileges,
not any privileges it might inherit
from roles granted to that user. This
means that the job will not run with
the ctxsys privilege that you should
have granted to your schema user. So
what does this mean? It means that you
have to run the job as the ctxsys user
I unfortunately cannot use this to grant myself privileges since yes, this is homework, and I don't have permissions to grant execute on ctx_ddl to myself.
Does anyone have clues as to how I can resolve this issue? Otherwise I will wait until later this week and consult the TA's.
Thanks
I don't think there's a workaround since the documentation of DBMS_JOB explicitly specifies this restriction:
You can execute procedures that are owned by the user or for which the user is explicitly granted EXECUTE. However, procedures for which the user is granted the execute privilege through roles cannot be executed.

Resources