Conference iosg::all-in-1_v30

    As you suggest, ALL-IN-1 raises privs to access this data set on behalf
    of unprivileged users.
    
    What actions it takes, if any, to prevent users maliciously (or
    accidentally) corrupting the file, I don't know.  Probably not many.
    
    Scott

    Re .0
    
    Don't worry about not understanding ALL-IN-1! I have been working on it
    for over six years and I still have no idea how some of it works...
    
    There are several places where the image uses its privileges to access
    data files. The PROFILE.DAT access is the most common one. Here the
    PROFIL dataset has a special action routine that carefully validates
    the calling user and the requested action before raising privs to
    access the file. To be strictly accurate, its the data action routine
    rather than the WRITE function, which decides to raise privs.
    
    Access to the mail shared areas is another place where privs are
    raised, again after careful checks.
    
    Perhaps the ex-archive developer will give us more details of how this
    works?
    
    Graham

    The way data data-sets (as opposed to text data-sets) work is this:
    
    The code searches a built-in list of data-sets for the name
    (ARCHIVE_DOCS_PENDING_RECOVERY  in this case).
    
    If it finds a data-set of that name, it uses it. If it doesn't, it uses
    a default data-set.
    
    In either case, it extracts the name of the "action routine" to use
    from the DSAB it found. In the default DSAB it's OA$RMS_ACTION. For
    PROFILE, the DSAB looks like:
    
            $DSAB(NAME='PROFIL',CLASS=DATA,
                    ACTION=OA$PROFIL_ACTION,
                    CACHE_USE=4,
                    CACHE_OPEN=32,
                    CHOICES=1,
                    PRIV = 1,
                    FILL=%C' ',
                    SIGNAL=1,
                    USER1=0,
                    USER2=0)
    
    Here, a special action routine (OA$PROFIL_ACTION) has been specified,
    which contains the code which allows users only to modify their own
    record, and even then only certain fields in that record.
    
    For ARCHIVE_DOCS_PENDING_RECOVERY, the DSAB looks like:
    
            $DSAB (NAME = 'ARCHIVE_DOCS_PENDING_RECOVERY',
                    ACTION = OA$RMS_ACTION,
                    CLASS = DATA,
                    PRIV=1,
                    SIGNAL=0,
                    FILL=%C' ',
                    CHOICES = 1)
    
    Here, the action routine is the default one, BUT the DSAB has specified 
    PRIV=1 which tells that action routine to turn on the image's privs
    before accessing the file. (This also applies to some of the other
    Archive data-sets).
    
    Now, exactly how this works I'll have to leave to the
    (ex-)archive developer.
    
    Dave.

    
    Hi Stefan,
    
    One thing I'm curious about is that your example of
    ARCHIVE_DOCS_PENDING_RECOVERY.DAT contains an ACL with an ACE for
    OA$MANAPP. OA$MANAPP doesn't need access to this file in any other way
    than a normal user, and the privileges 'built-in' will do their job for
    someone with OA$MANAPP also. 
    
    ???
    
    Ciao,
    
    	Simon

    Hi Simon,
    
    On my system which has been upgraded from V2.4 I have two
    ARCHIVE....DATs:
    
    $  dir /sec oa$data:ARCHIVE_DOCS_PENDING_RECOVERY.DAT/nodate
    
    Directory A1DISK:[ALLIN1.SITE.DATA_SHARE]
    
    ARCHIVE_DOCS_PENDING_RECOVERY.DAT;1
                             15  [ALLIN1]              (RWED,RWED,RE,RE)
              (IDENTIFIER=OA$MANAPP,ACCESS=READ+WRITE+EXECUTE+DELETE)
    
    Total of 1 file, 15 blocks.
    
    Directory A1DISK:[ALLIN1.DATA_SHARE]
    
    ARCHIVE_DOCS_PENDING_RECOVERY.DAT;11
                              3  [ALLIN1]              (RWED,RWED,RE,RE)
    
    Total of 1 file, 3 blocks.
    
    
    This is another problem I have to solve....Maybe someone has the same
    behaviour on an upgraded system. 
    
    Stefan

        Simon,
        
        our system shows exactly the same !
        
        Upgraded from 2.4 to 3.0 with K701 patch.
        The upgrade date is: 11-dec-1992.
        Look:


Directory ALLIN1$DATA:[DATA.SITE.DATA_SHARE]

ARCHIVE_DOCS_PENDING_RECOVERY.DAT;1
                        156  11-DEC-1992 18:46:31.69  OA$MANAPP             
(RWED,RWED,RE,RE)
          (IDENTIFIER=OA$MANAPP,ACCESS=READ+WRITE+EXECUTE+DELETE)

Total of 1 file, 156 blocks.

Directory ALLIN1$DATA:[DATA.DATA_SHARE]

ARCHIVE_DOCS_PENDING_RECOVERY.DAT;47
                          3   9-SEP-1993 01:05:53.05  [DESK,ALLIN1]         
(RWED,RWED,RWED,RE)
ARCHIVE_DOCS_PENDING_RECOVERY.DAT;46
                          3   2-SEP-1993 01:07:22.94  [DESK,ALLIN1]         
(RWED,RWED,RWED,RE)

Total of 2 files, 6 blocks.

Grand total of 2 directories, 3 files, 162 blocks.



	Strange around dates ???

	Kati

    Well this would seem to be a bug in the upgrade...
    
    The PostInstall Script ARC_PEND_CONV.SCP copies the existing 310 byte
    length record file into OA$DATA:V24_ARCHIVE_DOCS_PENDING.DAT, this of
    course goes to the first part of the OA$DATA search list, i.e.
    OA$SITE_DATA_SHARE. Then it goes on to do an OA$CNV_CONVERT of this
    file using the ARCHIVE_DOCS_PENDING_RECOVERY form, which since it too
    specifies OA$DATA as the file location, makes the converted (now 320
    byte length records) file go into OA$SITE_DATA_SHARE too.
    
    Since the installation has previously (correctly :-) ) put a default
    ACL for OA$MANAPP on the OA$SITE_DATA_SHARE directory, the new data
    files get that ACL too.
    
    Bit of course, all of this should still work, since the new version of
    the file will be found first...
    
    So the (tidy-up) workround is to move the newly converted file into
    OA$DATA_SHARE and get rid of the old version. Of course, if you are
    runing the reorganise files housekeeping procedure, it specifically
    references the file with OA$DATA_SHARE, and $CONVERT/FDLs the old file
    into its new record length....
    
    I'll report this internally!
    
    Graham

    Of course this still doesn't explain how the file described in .0 got
    OA$MANAPP on it, since that system had the data file correctly placed
    in OA$DATA_SHARE...
    
    Graham