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

Conference csc32::consolemanager

Title:POLYCENTER Console Manager
Notice:Kits, Scans, Docs on CSC32:: as PCM$KITS:,PCM$DOCS:, PCM$SCANS:
Moderator:CSC32::BUTTERWORTH
Created:Thu Aug 06 1992
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:1541
Total number of notes:6564

581.0. "EXIT from multi-line event list gives audit message" by KETJE::MICHIELS (OpenVMS: No compromise computing!) Thu Jan 26 1995 16:23

    I noticed the following minor problem with consolemanager.
    I'm using V1.5-006 on OpenVMS VAX.

    When you exit from a multi-line event list window, a message is generated
    by the audit server.
    Apparently CONSOLE$ENS_DAEMON.EXE tries to delete the log file, while
    this file is still open for write.

    Below the message from the audit server.
    
    Johan

    

%%%%%%%%%%%  OPCOM  26-JAN-1995 17:10:06.12  %%%%%%%%%%%
Message from user AUDIT$SERVER on KWAK
Security alarm (SECURITY) on KWAK, system id: 54932
Auditable event:          Object deletion
Event information:        file deletion request (IO$_DELETE)
Event time:               26-JAN-1995 17:10:06.11
PID:                      00000B40
Process name:             Console Notify
Username:                 SYSTEM
Process owner:            [DIGITAL,SYSTEM]
Image name:               DSA0:[CONSOLE.][IMAGES]CONSOLE$ENS_DAEMON.EXE
Object class name:        FILE
Object owner:             [DIGITAL,SYSTEM]
Object protection:        SYSTEM:RWED, OWNER:RWED, GROUP:RE, WORLD:
File name:                _DSA0:[CONSOLE.TEMP]MULTI-LINE__002.LOG;2
File ID:                  (6730,37,0)
Access requested:         DELETE
Sequence key:             00BE2817
Status:                   %SYSTEM-W-ACCONFLICT, file access conflict
    
T.RTitleUserPersonal
Name
DateLines
581.1CSC32::BUTTERWORTHGun Control is a steady hand.Thu Jan 26 1995 21:2518
    >I'm using V1.5-006 on OpenVMS VAX. When you exit from a multi-line 
    >event list window, a message is generated by the audit server.
    
    More than likely you are setup to log unsuccessful object deletions
    
    >Apparently CONSOLE$ENS_DAEMON.EXE tries to delete the log file, while
    >this file is still open for write.
    
    Correct.
    
    Regs,
      Dan
    
    
    
    
    
    
581.2The exit makes the window re-appear ...KETJE::STAESTopless = No brains at allSat Jan 28 1995 11:2319
>    More than likely you are setup to log unsuccessful object deletions

    Yes.  That's what security audit/alarms are used for.
    
>    >Apparently CONSOLE$ENS_DAEMON.EXE tries to delete the log file, while
>    >this file is still open for write.
>    
>    Correct.
    
    Eh?  Correct, but probably not what you wanted.  The alarm triggers the
    re-creation of the security message window which you just tried to exit 
    from...  Maybe time for a purge/delete option via a (startup) logical?

    Nand.
    
    (Who's analysing the security logfiles every day, and has an ENS security
    window under his nose. <-) )
    
             
581.3KETJE::MICHIELSOpenVMS: No compromise computing!Sun Jan 29 1995 11:4419
re .1
Dan,
    
What I wanted to point out it the fact that CONSOLE$ENS_DAEMON.EXE tries
to delete a file that is still open for write. As this is not possible,
the files remains in CONSOLE$TMP.

I've got other PCM action routines where the log file is deleted upon 
successfull completion (unless debug is on). I believe this is the wanted
behaviour, but for one reason or another this fails for the multi-line
event list window.

It's indeed a detail; I even don't want to call this a bug.
Probably easy to fix this.


Johan
    
    
581.4CSC32::BUTTERWORTHGun Control is a steady hand.Fri Feb 03 1995 16:3417
    >Yes. That's what security audit/alarms are used for.
    
    I guess I'm supposed to be humbled by this remark ...
    
    EH!!!??
    
    
    Re -1/
    
    Yes, it should be easy to fix. My reponse in .1 was simply designed to
    confirm your suspicions. In no way was I implying that it was the
    correct behavior.
    
    Regards,
       Dan