Conference iosg::all-in-1_v30

    
    	Do a site defined function called NEWDIR that does nothing.
    
    	You wiull have to be careful though, lots of the system manager
    	scripts use it (eg empty wastebaskets).
    
    Regards,
    Paul

    So it's better to write an SDF that checks the calling account, and
    lets it work if it's the Manager asking.
    
    This has been discused before in this or previous versions of this
    conference.
    
    Graham

    Further...
    
    Why do you want to do this anyway? What are you trying to stop
    happening.
    
    You can't NEWDIR into an account unless you have access (write I
    think) to their DOCDB, and unless the account is set up incorrectly,
    the person doing the NEWDIR probably has enough privileges to get round
    your checks anyway.
    
    Graham

    Gidday,
    
    Firstly thanks for the quick reponse.
    
    I don't have all the details but let me try and paint the picture
    anyway.
    
    They will/or are using ALL-IN-1 V2.4 (Turkish)
    
    The customer wants to stop the ALL-IN-1 manager account from accessing
    other users ALL-IN-1 accounts. 
    
    (this doesn't mean they want to interfere with the housekeeping jobs)
    
    regards
    LT  

    re: .4
    
    I am not sure that I agree with what they are trying to do since it
    sounds like they have a serious problem if they are not willing to
    trust their manager.  If you limit the ALL-IN-1 manager too much he/she
    will not be able to do his job properly and any partial restrictions
    are not foolproof.
    
    That said, it sounds like what you would need to do for .4 is write a
    site-defined NEWDIR function that checked the process mode for BATCH
    (rather than INTERACTIVE) as well as the username.  You can make these
    checks with the $GETJPI system service.  If the check is successful the
    routine could then call the standard NEWDIR routine; otherwise it would
    abort with an error message.  This should be a fairly simple routine.
    
    I hope this helps.
    
    John

    However, if this evil manager of theirs is a really good hacker, s/he
    can get round John's suggestion as well (by writing a batch job to do
    whatever evil things s/he has in mind).
    
    I don't think there's a foolproof way to make the Site Defined NEWDIR
    distinguish between legitimate uses (by housekeeping jobs) and naughty
    uses. If you think about it, it's logically almost impossible.
    
    I would agree with John's first paragraph.
    
    Dave.

    Of course, the customer is _always_ right, yes?
    
    D.

    There was a tool in the old US Assets library which provided a security
    feature for NEWDIR and SPAWN.  The package provided site defined
    functions which checked an access file to determine whether the calling
    users was allowed to perform the function.  In addition, all accesses
    and uses of the functions were logged to a file.

    I just helped connect a field person and the developer for it a couple
    of weeks ago.  I will send mail to the developer asking that she visit
    this note.  My policy is to not post peoples' names without their
    permission.

    The other approach, of course, is to request the SECURE FUNCTION
    package from the existing ASSETS library.  It was my understanding that
    the retired packages could still be pulled but with zero support.

    Of course, I could be wrong.  (about the ASSETS folks giving out old
    packages).

    Have fun,
    don

    my infamous customer had written a procedure last year that uses the
    NEWDIR function to go into each users account, select documents from
    the READ and OUTBOX folders that are older that x months and then do a
    cabinet delete_document.
    
    there is some concern now that maybe this isn't the most effective
    (less error-proof) was to go.  is ther a better way to code this...
    what potential problems might develop by running this...
    
    the comparison date is set in the .com procedure that calls this
    script.
    the OA$SITE_LIB_SHARE:3M_PURGE_FOLDERS2.SCP does the actual delete of
    the document.
    
    thanks - ann
    
    ! Get the account and directory we are currently in
    !
        GET #USER = OA$USER
        GET #CUR_DIR = PROFIL.DIRECT[#USER]
    !
    ! Loop through PROFIL and NEWDIR to valid accounts
    !
    !    FOR PROFIL WITH .VMSUSR NES "A06233" DO -
    !    FOR PROFIL WITH .USER GTS "SAAA" DO -
        FOR PROFIL WITH .NODE EQS "" DO -
            .IF .DIRECT NES "" THEN GET OA$FUNCTION = "NEWDIR " .USER \\ -
            GET #NEWUSER = .USER \\ -
            GET #SMDOC = OA$DIR:"*.*".%WHOLE["DOCDB.DAT"] \\ -
            GET #SMDAF = OA$DIR:"*.*".%WHOLE["DAF.DAT"] \\ -
            GET #DIR   = OA$DIR:"*.*".DEV["*.*"] OA$DIR:"*.*".DIR["*.*"] \\
    -
            .IF #SMDOC NES "" AND #SMDAF NES "" AND #CUR_DIR NES #DIR -
              THEN DO OA$SITE_LIB_SHARE:3M_PURGE_FOLDERS2.SCP \\\\ -
              GET #CUR_DIR = #DIR
    !
    ! Return to originating A1 account
    !
        GET OA$FUNCTION = "NEWDIR " #USER
    .
    .
    .
    

    Re .9
    
    There is a known problem that if you have global buffers on the SDAFs
    then doing NEWDIR in a loop through the profile will cause memory
    exhaustion.
    
    If you're on V3.0 ( or later ;^) ) then you can use the CABINET
    SET_DRAWER function instead of NEWDIR. Look at the EW housekeeping
    procedure for an example.
    
    I assume you know that what your customer is doing is identical (or
    seems to be) to the Mail Janitor Utility?
    
    Cheers
    
    Stuart

    thanks stuart -
    
    >If you're on V3.0 ( or later ;^) ) then you can use the CABINET
    >SET_DRAWER function instead of NEWDIR. Look at the EW housekeeping
    >procedure for an example.
     	this site is at 2.4 right now, but will be going to 3.0 in the next
    	few months.
    	this should still work with NEWDIR in 3.0 right?
    
    >I assume you know that what your customer is doing is identical (or
    >seems to be) to the Mail Janitor Utility?
     	it was written before i became involved, but i'd guess that they
    	didn't want to spend the money on mailjanitor.
    
    ann

    Re .11
    
>    	this should still work with NEWDIR in 3.0 right?
    
    Yes - but the NEWDIR and global buffers problem survives in V3.0
    
    Cheers
    
    Stuart