Conference iosg::all-in-1_v30

    Unfortunately you can't do this.
    
    The EXECUTE function, as you spotted, resets the privileges after
    return from the EXECUTEd function (to what they were before). This was
    actually done to prevent the function _increasing_ the privs and
    leaving them that way, but it will also stop the function _reducing_
    the privs.
    
    I suppose the only answer is the usual one about not giving privs to
    users who you (the customer that is) don't trust. Users with Admin priv
    can do  all (almost all) the day-to-day things which normally reuiqre
    privs.
    
    However, I can see that your customer's requirement is valid. Have you
    thought about doing it by customising the named data/forms so the
    shared drawers the user shouldn't see are hidden (I'm not sure how you
    would do this; just thinking aloud)? Of course, the determined hacker
    can get round this, but then you can't stop a determined hacker who has
    privs no matter what you do.
    
    Sorry,
    Dave.

    Hi Dave,
    
    One other way around this would be to define a site defined function. 
    Can you see any drawer backs with this ?  It seems a better way of
    doing things, have you or anyone else got any comments regarding this
    approach ?  I would appricate your input.
    
    I suppose this should really be part of a wish list.  It looks like
    some government sites are asking for security features such as an audit
    trail.  They would like a report of all the people who accessed
    documents and what they did ir edit or read.
    
    Having come across a number of government departments they feel that
    ALL-IN-1 IOS now lack security features.  A management tool ie a
    security sub-system would address some of their concerns.  I wonder if
    this can be put on the WISH LIST.
    
    Regards,
    
    Sunil

    Yes, you could certainly write a site-defined function to do this (or
    anything else, more or less!)
    
    Dave.

    Hi Dave,
    
    I have not integrated a site defined function before and I thought the
    manual was quite good (Application Programming Guide Chapter 24).
    
    We have run into a few problems in that the customer has been hacking
    around with the link procedures, luckly he kept track of what he had
    been doing.  So we put everything back to what it was like.
    
    Now to integrate a site defined function you just have to create a 
    sitelink30.com and enter the following:
    
    $ write opt "<directory spec.>:routine_name.obj"
    
    This would to my mind write the routine name into the optional file and
    link the SDF into the OA$MAIN image.  We followed pages 24-13 onwards
    and copied in OA$SCT$SDF to CM and created the "Table of site-defined
    functions" etc.  The reason I mention the above is because it's missing
    from the documentation so I thought it would be helpful to those of us who
    have not yet SDF'd :-).
    
    Everything had gone to plan, however (there as to be one of those
    :-)!!) this is what happens when we did some testing :
    
    We enter PRIV() at the MAIN menu than WP FC DRM ADR and Gold L, the
    user now cannot see the drawers that he has no access to, great :-)!!!
    
    We enter PRIV() at the WP menu than FC DRM ADR and Gold L, the user can
    still see the drawers, no so great :-( !!!
    
    Is there a reason why this happens ?  Does WP and/or EM (must admit we
    did not test EM), save the privs. when you enter these two sub-system ?
    If so is there away around this ?  If not we are back to the drawing
    board unfortunately :-{.
        
    Regards,
    
    Sunil

    I think you'll have to call your PRIV() function quite often.
    
    The problem is that if ALL-IN-1 does anything that causes it to turn on
    its installed privs, it'll dutifully turn them "off" again afterwards.
    Trouble is that its interpretation of "off" is "reset to what they were
    when the image started", NOT "reset to what they were before I just
    turned them on" (this saves a system service call or two).
    
    One of the things that'll cause ALL-IN-1 to turn on its privs is
    getting the unread mail count, which is in the named data of various
    forms - this could be your problem. Don't forget that almost anything
    to do with mail (such as reading a _message_, not a _document_, or
    sending, attaching, detaching etc a message) will turn the privs on and
    "off".
    
    So you'll need to put your PRIV() function call just before it's
    needed, i.e. in the named data of FC or DRM or ADR.
    
    Try this and see what you get.
    
    One hint - you can see the process priv masks by using SDA ($ANAL/SYS)
    from another process. This might help you see what's happening.
    
    Dave.

    G'Day Sunil,
    
    Let me see if I can't give you a hand on this problem...
    
    Firstly, I'd just like to check on my understanding of the problem:
    
    Users with SYSPRV or BYPASS privileges are granted access to shared
    drawers even when they have not explicitly been authorized for that
    access. The same is true of System UICs (you can't turn these off using
    $SETPRV !).
    
    Well, assuming that is the problem, and assuming you've heard the
    long-winded explanation I normally give [in SPR answers] then you'll
    know that this is a phenomenon of VMS as much as ALL-IN-1.
    
    Whatever we do to ALL-IN-1, it will not stop VMS users from gaining
    access to files in shared drawers. Users with privileges can do this
    always. It can take a bit of figuring out as to which document is
    which, but the fact is that VMS privileges are designed to bypass
    access control mechanisms and we can't do anything about that.
    
    Turning to the question in hand, there are several options available of
    which you have chosen one:
    
    	- Disable privileges at image startup and re-enable at exit
    	- Implement an INSTALL/EXECUTE function to enable/disable privs
    	- Implement an SDF to turn privs on and off
    
    Turning off privs at startup is perhaps the most sensible, but it isn't
    flexible. INSTALL/EXECUTE is the easiest technique as it's documented.
    SDF is not too hard, but you want to avoid it if you can.
    
    Now, as Dave has pointed out... 
    
    The problem you are having is that ALL-IN-1 only gets the privileges
    once and sets a flag to say that it's recorded the process privileges.
    
    Thus any time ALL-IN-1 turns off privileges, it will go back to it's
    definition from the first time it was called to turn them on or off.
    This applies not only to INSTALL/EXECUTE but also to SDFs and lots of
    activity inside ALL-IN-1 causes switching to take place. [e.g.
    everytime you use DDS, operate on shared area documents, etc etc.]
    
    So, your only solution it to reduce the PROCPRIV at image startup.
    
    This can be done using LIB$INITIALIZE and by declaring an exit-handler
    to restore privileges on the way out of the image. Then adding a module
    to the link may require you to customize A1LINK.COM because order may
    be significant for including the LIB$INITIALIZE routine. You can check
    by just trying such code in SITELINK30.COM first to see if it has the
    desired effect. If not, you'll need to put it somewhere further up the
    list of initialization modules (i.e. earlier in the generated
    A1LINK.OPT file) by changing A1LINK.COM.
    
    Not good news from your customer's perspective, but THE news.
    
    Paul.

    G'day Paul,
    
    >This can be done using LIB$INITIALIZE and by declaring an exit-handler
    
    The problem is that LIB$INITIALIZE is not documented nor is it's use
    encouraged, so getting an example would be great if at all possible
    I don't really expect to get an example though :-).
    
    By the way I have gone through other ways a determined user can hack
    around this from OpenVMS etc. with the customer.  But they are
    determined to go ahead with this no matter what, civil servants can be
    a bit of a pain in the neck at times !!!!
    
    By the way I had suggested that the customer puts the function call in
    OAINI.SCP, this worked and the privs. were set correctly during the
    entire login session.  BUT there was a slight loop hole in that if a
    user had set his Main screen up other than MAIN and than ONINI got
    executed it was too late.
    
    Thanks for your help, regards,
    
    Sunil

    Hi Paul,
    
    Just discovered an example in Stars and have found out from the OpenVMS
    group that LIB$INITIALIZE is support BUT the use of is strongly
    discouraged.
    
    If anyone wants to see the example just type in LIB$INITIALIZE, the
    example is in C.
    
    By the way to call this routine do you just add the following line in
    sitelink30.com $ write opt "routine name" ?
    
    Thanks,
    
    Sunil

    re: .8
    
    >By the way to call this routine do you just add the following line in
    >sitelink30.com $ write opt "routine name" ?
    
    It should be:
    
    	$ write opt "object-module-name"
    
    which may or may not be the same as the routine name.
    
    You can also find the examples from my book in the CLI conference if
    you need another sample.
    
    John

    Sunil,
    
    I can't exactly recommend interfering with ALL-IN-1 at this level
    either because it's not officially supported.
    
    Having said that though, I can't see LIB$INITIALIZE going away in a
    hurry and if it does, there are 20+ modules in ALL-IN-1 which use it to
    hook in for initializations [including such beasts as WPS-PLUS] which
    will need to think up some other way of doing their bit.
    
    In fact, I think there may even be support for initialization routines
    in shareable images very soon on VMS [through LIB$FIND_IMAGE_SYMBOL] so
    support is expanding rather than contracting.
    
    Add to this the fact that there is no other way of doing what they want
    and I'm sure they will 'wear the risk' of it not working in the future. 
    
    Of course, you can't give it to them as an officially supported
    software component but 'examples' are fine.
    
    Let me know if you still can't get what you need out of the CLI
    information available and I'll see what I can do.
    
    Paul.
    

    Hi Dave,Paul and John,            
    
    Thanks for your help the customer has successfully achived what was   
    required.  On my part I have learnt a bit about SDF's.
    
    For those interested the documentation for LIB$INITIALIZE can be found
    in chapter 7 of LIBRTL manual and/or Guide to Modular Procedures for
    doc on LIB$INITIALIZE.  As a reminder LIB$INITIALIZE is supported but
    strongly discouraged.
    
    Regards,
    
    Sunil
    
    PS - I have had my Wisdom tooth problems sorted out , until the next time 
    :-(.  Well I am more the wiser for it now :-). Don't have Wisdom teeth 
    ( =====), see one is missing :-).