[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference orarep::nomahs::rdb_60

Title:Oracle Rdb - Still a strategic database for DEC on Alpha AXP!
Notice:RDB_60 is archived, please use RDB_70..
Moderator:NOVA::SMITHISON
Created:Fri Mar 18 1994
Last Modified:Fri May 30 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:5118
Total number of notes:28246

4965.0. "rmu/set audit/enable=daccess=table=all???" by BROKE::BASTINE () Mon Jan 27 1997 12:10

I have a ? on AUDITING.

A customer wants to be able to turn on alarms for ALL tables with /PRIV=ALL
for DACCESS type auditing for 2 particular users.

I have been playing with all the commands we need and we have them all, except,
we are looking for a quick and easy way to get ALL tables.

For example:

rmu/set audit/type=alarm/enable=daccess=table=(employees)/priv=all personnel

will turn on the alarms when this user (we already enabled the identifiers)
access the employees table and it all works, but the customer has hundreds
of tables they want to turn on with /priv=all.  I tried this:

rmu/set audit/type=alarm/enable=daccess=table=(*)/priv=all personnel

and although the syntax is accepted, nothing is ever done on the audit 
side.  I can still access all tables without receiving an alarm.

Does anyone know of a way to list ALL tables quickly without specifying them
individually?  What the customer wants to accomplish is this:

rmu/set audit/type=alarm/enable=daccess=table=(*)/priv=all personnel

where * indicates ALL tables in the personnel database.

The rest of the auditing functions have been enabled and are working 
appropriately, we are just looking for a short way to specify DACCESS alarms
for all tables.


Thanks,
Renee
T.RTitleUserPersonal
Name		DateLines
4965.1or the com wayM5::JHAYTERMon Jan 27 1997 14:0818
>Does anyone know of a way to list ALL tables quickly without specifying them
>individually?  What the customer wants to accomplish is this:
>
>rmu/set audit/type=alarm/enable=daccess=table=(*)/priv=all personnel

NO, but sometimes you have to do it the hard way.

$ set noverify
$ define sys$output rmu_set_audit.com
$sql
set line length 132
select
'$rmu/set audit/type=alarm/enable=daccess=table=(',
cast(RDB$RELATION_NAME as char(31)), -- cast to get rid of col header
')/priv=all personnel'
from rdb$relations where RDB$SYSTEM_FLAG=0;
$ deassign sys$output
4965.2How do you disable rmu access!!!BROKE::BASTINEWed Jan 29 1997 09:3838
Thanks Jerry!

  The customer is using the command file and is very grateful!!

I have one other question on auditing... 

I have RMU access alarms disabled, why would I still be seeing RMU commands
in an alarm?

Security alarms STARTED for:
    PROTECTION (disabled)
    RMU (disabled)
    AUDIT (enabled)
    DACCESS (enabled)


DBS400> rmu/show audit/all personnel
%%%%%%%%%%%  OPCOM  29-JAN-1997 09:32:43.91  %%%%%%%%%%%
Message from user SQLUSER61 on DBS400
DEC Rdb Security alarm (SECURITY) on DBS400, system id:  44234
Database name:          SYS$COMMON:[SQLUSER61]PERSONNEL.RDB;1
Auditable event:        Attempted database access
PID:                    00000323
Event time:             29-JAN-1997 09:32:43.90
User name:              SQLUSER61
Object name:            SYS$COMMON:[SQLUSER61]PERSONNEL.RDB;1
Object type:            DATABASE
Operation:              RMU Command
Access requested:       DBADM
Sub status:             Rdb required privilege
Final status:           %SYSTEM-S-NORMAL
Rdb privilege used:     DBADM


I have stopped and started the alarms as RMU was enabled at one point, but
now I can't shut it off!!

Renee
4965.3caotv2.ca.oracle.com::BZINN[email protected]Wed Jan 29 1997 10:527
    Renee,
    
    What version? I BUGd a problem with getting them turned off a while
    back - # 329488 (I don't remember any details) and it did get fixed in
    one of the ecos.
    
    Brenda
4965.4I'm using 6.1ABROKE::BASTINEWed Jan 29 1997 10:584
I am using 6.1A.  The customer is using 5.1.

- Renee
4965.5Perhaps a new symptom???BROKE::BASTINEWed Jan 29 1997 11:0974
I just read the bug...

The details of the bug are that rmu/set audit/type=alarm/stop did not stop
them.  As a workaround you had to use rmu/set audit/disable=rmu.

My problem isn't that rmu/set audit/type=alarm/stop doesn't stop ALL alarms,
it does,  but
rmu/set audit/disable=rmu does not disable RMU alarms!  If you turned them
on, they seem to be turned on forever whether or not you disable them!

Since the customer is on v5.1 he might be running into some known issues
with auditing and rmu alarms, I'll let him know, but I am still having
some problems in 6.1A.

Please notice that at the bottom of this output, RMU is DISABLED, but
an rmu/show audit/all personnel still displays a alarm for the RMU command.

DBS400> rmu/show audit/all personnel
%%%%%%%%%%%  OPCOM  29-JAN-1997 11:07:03.31  %%%%%%%%%%%
Message from user SQLUSER61 on DBS400
DEC Rdb Security alarm (SECURITY) on DBS400, system id:  44234
Database name:          SYS$COMMON:[SQLUSER61]PERSONNEL.RDB;1
Auditable event:        Attempted database access
PID:                    00000323
Event time:             29-JAN-1997 11:07:03.29
User name:              SQLUSER61
Object name:            SYS$COMMON:[SQLUSER61]PERSONNEL.RDB;1
Object type:            DATABASE
Operation:              RMU Command
Access requested:       DBADM
Sub status:             Rdb required privilege
Final status:           %SYSTEM-S-NORMAL
Rdb privilege used:     DBADM

%%%%%%%%%%%  OPCOM  29-JAN-1997 11:07:03.31  %%%%%%%%%%%
Message from user SQLUSER61 on DBS400
DEC Rdb Security alarm (SECURITY) on DBS400, system id:  44234
Database name:          SYS$COMMON:[SQLUSER61]PERSONNEL.RDB;1
Auditable event:        Attempted database access
PID:                    00000323
Event time:             29-JAN-1997 11:07:03.30
User name:              SQLUSER61
Object name:            SYS$COMMON:[SQLUSER61]PERSONNEL.RDB;1
Object type:            DATABASE
Operation:              Attach Database
Access requested:       SELECT
Sub status:             Rdb required privilege
Final status:           %SYSTEM-S-NORMAL
Rdb privilege used:     SELECT

Security auditing STOPPED for:
    PROTECTION (disabled)
    RMU (disabled)
    AUDIT (enabled)
    DACCESS (enabled)

Security alarms STARTED for:
    PROTECTION (disabled)
    RMU (disabled)
    AUDIT (enabled)
    DACCESS (enabled)

Audit flush is disabled

Audit every access

Enabled identifiers:
    (IDENTIFIER=[SQLUSER61])
                                     


If this is still broken, I'll submit a new bug.

Renee
4965.6More information, I can turn them off if account nobypassBROKE::BASTINETue Feb 04 1997 09:3266
I've been playing with this quite a bit and figured out what is happening.

It appears if an account has BYPASS priv's set on his/her account, then
all RMU commands are audited/alarmed if that account has REPLY/ENABLE
turned on.  The RMU commands are tracked regardless of whether or not 
they are enabled or disabled!!!  To be sure you get a true picture of what
you want to see in the alarms, be sure the account used to "track" the 
alarms does not have BYPASS priv turned on, or they may see alarms for RMU
commands that are supposedly "disabled".  If BYPASS is taken off of the
account, the RMU commands are alarmed as they should be.

For example, if I set all my priv's so BYPASS is enabled, AND I disable 
RMU command alarms, I see RMU alarms.  But if I set proc/priv=nobypass, I 
do not see those RMU command alarms:

DBS400> set proc/priv=all
DBS400> rmu/set audit/disable=rmu personnel
DBS400> rmu/show audit/all personnel

%%%%%%%%%%%  OPCOM   4-FEB-1997 09:26:30.71  %%%%%%%%%%%
Message from user SQLUSER70 on DBS400
DEC Rdb Security alarm (SECURITY) on DBS400, system id:  44234
Database name:          SYS$COMMON:[SQLUSER61]PERSONNEL.RDB;1
Auditable event:        Attempted database access
PID:                    00000399
Event time:              4-FEB-1997 09:26:30.70
User name:              SQLUSER70
Object name:            SYS$COMMON:[SQLUSER61]PERSONNEL.RDB;1
Object type:            DATABASE
Operation:              RMU Command
Access requested:       DBADM
Sub status:             Rdb required privilege
Final status:           %SYSTEM-S-NORMAL
Rdb privilege used:     DBADM


If I then turn off bypass, the RMU alarms are not displayed, as it should
be:

DBS400> set proc/priv=nobypass
DBS400> rmu/show audit/all personnel
Security auditing STOPPED for:
    PROTECTION (disabled)
    RMU (disabled)
    AUDIT (enabled)
    DACCESS (enabled)

Security alarms STARTED for:
    PROTECTION (disabled)
    RMU (disabled)
    AUDIT (enabled)
    DACCESS (enabled)

Audit flush is disabled

Audit every access

Enabled identifiers:
    (IDENTIFIER=[SQLUSER61])


Should the alarms be surpressed when they are disabled even it the account
with REPLY/ENABLE=SECURITY set has BYPASS priv's?

Thanks,
Renee