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

Conference iosg::all-in-1

Title:ALL-IN-1 (tm) Support Conference
Notice:Please spell ALL-IN-1 correctly - all CAPITALS!
Moderator:IOSG::PYECE
Created:Fri Jul 01 1994
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2716
Total number of notes:12169

2628.0. "Security alarms on shared directory access" by COPCLU::ELIN (Elin Christensen @DMO, DTN 857-2406) Thu Apr 17 1997 16:27

On Tele Danmark they get these security alarms on the console all the time
with different user names requesting READ,WRITE access to OA$SHAR* directories.

15:32:05 Security alarm (SECURITY) and security audit (SECURITY) on JULIE, syst
15:32:05 Auditable event:          Object access
15:32:05 Event information:        directory entry creation request (IO$_ACCESS
15:32:05 Event time:               17-APR-1997 15:32:04.72
15:32:05 PID:                      2040E5DA
15:32:05 Process name:             _OA$F5CE_000034
15:32:05 Username:                 A57052
15:32:05 Process owner:            [A57052]
15:32:05 Terminal name:            MBA2990
15:32:05 Image name:               DSA2:[ALLIN1.OA$EXE_VAX_SHARE]OA$MAIN.EXE
15:32:05 Object class name:        FILE
15:32:05 Object owner:             [ALLIN1]
15:32:05 Object protection:        SYSTEM:RWE, OWNER:RWE, GROUP:E, WORLD:E
15:32:05 Directory name:           _DSA15:[OA$SHARB]SHARB787.DIR;1
15:32:05 Directory ID:             (3780,3,0)
15:32:05 Directory entry:          ZWUMM72V9.TXT;0
15:32:05 Access requested:         READ,WRITE
15:32:06 Sequence key:             1C6251F9
15:32:06 Status:                   %SYSTEM-F-NOPRIV, insufficient privilege or


OA$MAIN has these privileges:

DISK$DISK02:<ALLIN1.OA$EXE_VAX_SHARE>.EXE
   OA$MAIN;7        Open Hdr Shar Prv
        Entry access count         = 14459
        Current / Maximum shared   = 4 / 17
        Global section count       = 6
        Privileges = CMKRNL SYSNAM GRPNAM DETACH GROUP TMPMBX WORLD OPER
                     EXQUOTA NETMBX SYSGBL SYSPRV BYPASS SYSLCK


It happens on their VAX cluster. They have not reported the same thing on
the Alphas (and I have not asked yet).

Could somebody tell me what can be wrong?

Elin
T.RTitleUserPersonal
Name		DateLines
2628.1ALL-IN-1 won't privs unless logical EXECTAY2P1::HOWARDWhoever it takesFri Apr 18 1997 23:447
    Does the process eventually get access, or does it fail?  Is the
    logical OA$SHARB787 defined as /EXEC on node JULIE?  Are all shared
    areas affected the same?  In really old versions, this was normal, but
    I think since at least V2.4 it has not been. You mentioned Alphas, so I
    expect that you are running at least V3.1 on the VAX. 
    
    Ben
2628.2Inspect??COPCLU::ELINElin Christensen @DMO, DTN 857-2406Wed Apr 23 1997 12:4975
    
    I don't know if the process actually gets access or if it fails.
    The customer reported that they have got these alarms,
    - not that users had problems sending mail.
    
    There are three mail areas, OA$SHARA, OA$SHARB, OA$SHARE.
    Only OA$SHARB is open.
    All the alarms are on OA$SHARB directories.
    All OA$SHARBnnnn logicals are defined in EXEC mode.
    All users use OA$SHARB and have been doing that for long time. 
    
    We see the alarms on both cluster nodes.
    It's ALL-IN-1 v3.1 and OpenVMS V6.2.
    The nodes have last been booted 18-MAR and 19-MAR. 
    The first of these alarms occurred 10-APR-1997 16:09.
    
    We don't see alarms like these on the customer's two Alpha clusters.
    
    ---
    
    I have just found out that INSPECT LOCKDOWN has been run for the first
    time on this system 10-APR-1997 at 16:05.
    This was just before we got the first alarm!
    (Inspect lockdown has not yet been run on the customer's two other
    ALL-IN-1 systems.)
    
    Owner has been changed from [ALLIN1] to [SYSTEM] on 000000.DIR
    directories and this ACL has been set:

    Directory DSA15:<000000>
    
    000000.DIR;1         [SYSTEM]                         (RWED,RWED,RE,E)
             
    (DEFAULT_PROTECTION,SYSTEM:RWED,OWNER:RWED,GROUP:RE,WORLD:,OPTIONS=
              PROTECTED+NOPROPAGATE)
    
    
    
    Owner has been changed from [ALLIN1] to [SYSTEM] on AIDA images that
    were not locked while the Inspect lockdown ran:
    
    AIDA_CLI.CLD;2       [SYSTEM]                         (RWED,RWED,RE,RE)
    OA$AIDA_CLI.EXE;4    [SYSTEM]                         (RWED,RWED,RE,RE)
    OA$AIDA_DDS.EXE;4    [SYSTEM]                         (RWED,RWED,RE,RE)
    
    OA$AIDA_CSHR.EXE;4   [SYSTEM]                         (RWED,RWED,RE,RE)
    
    
    
    Audit has been enabled for 
      FILE access:
        Failure:     read,write,execute,delete,control
    
    This was not enabled before 10-APR.
    
    
    This is all I find can influence ALL-IN-1 of the things mentioned in
    the Inspect report.
    
    My guess is that there is an error which has always been there, and
    that we have not seen it before because AUDIT has not been enabled on
    file access failures before.
    
    There are 2800 occurences of this alarm since 10-APR on a little more
    than 600 different users. 
    There are alarms on practically all directories in the OA$SHARB write
    window (687 of 700). 
    
    So I guess that this alarm occurs every time a user creates a mail.
    
    Could someone explain 
    	- WHY do we get those messages?  
    	- HOW do we get rid of them?
    
    Elin
2628.3IOSG::PYEGraham - ALL-IN-1 Sorcerer&#039;s ApprenticeFri Apr 25 1997 12:598
    The AIDA images should already have been set to be owned by SYSTEM
    during the installation, along with any files that we put in "SYSTEM"
    directories (e.g. SYS$SHARE, etc.)
    
    I'm not sure about the effect of the directory ownership. Could you
    reverse it and see if that fixes the problem. I can't see why we should
    object to that, so perhaps it's always been a bug, in which case, IPMT
    it!