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

Conference smurf::dec_mls_plus

Title:dec_mls_plus
Moderator:SMURF::BAT
Created:Mon Nov 29 1993
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:534
Total number of notes:2544

510.0. "setting up multiple single-level applications" by SMURF::BAT (Segui la tua beatitudine) Thu May 15 1997 23:53

    John McNulty called today and said that tomorrow he has to go and
    install a demo MLS+ V4.0A system or systems.  He is being asked to
    set up three separately labelled single-level file systems that are to
    served by [one or more] browsers.  He said someone had done it on a Sun
    and we are invited in for comparison purposes.
    
    We discussed some options and issues involved in setting up three
    single-level applications at the same time, e.g., creating single-level
    file systems and mounting them at the required SL, vs. creating a
    multi-level file system at a given SL and then mounting it;  and
    whether it is possible to just have one copy of the application or
    would there have to be three different ones? 
    
    I said it depends on the application implementation, and gave some
    examples.  Sometimes it is possible to have just one, and as each user,
    at a different SL launches a copy, it runs at the user's process SL. 
    And even if the application writes or maintains control files, it is
    still sometimes possible to just have one application using the same
    set of defaults if you make use of "MLD" or "hidden" directories to
    make it transparent to the application which set of files it is writing
    at which level.
    
    But for servers, that usually doesn't work.  You'd really have to
    modify the server to be a trusted application so that it could launch
    subprocesses at the SL of the connecting client.  The advantage to
    having a multi-level browser would be that you wouldn't have to have
    three separate databases, you could have all the data in one and this
    would enable a user with a "TS A B" process to read all the data, and
    not have to run a different browser to see data his process dominates.
    
    If they are not planning on modifying the browser to be multi-level (as
    did Oracle for their http server), then they are probably going to want
    to launch multiple copies in init or startup using epa to set the SL of
    that particular copy of the browser, and set up each copy to be
    listening on a different port. 
    
    So when "CONFIDENTIAL A B" users connect (via an interface configured
    single level, for example), they would have to connect to port 8081, if
    they are "SECRET A B" users they would connect to 8082 and so on.
    
    I made all this up as I went along, and invite comments.
    
    John said he'd call tomorrow if he runs into snags -- Rick if early, me
    or Lee if late.
    
T.RTitleUserPersonal
Name
DateLines