Conference iosg::all-in-1_v30

2244.0. "ALL-IN-1 V3.0 problems with drawers" by OTOOA::BCARR () Wed Feb 10 1993 19:38

Howdy all,


I have just recently upgraded a customer site from ALL-IN-1 V2.4 to ALL-IN-1
V3.0.  Since the upgrade I have noticed a couple of problems.



1.  I had two users create private drawers and move docuements into them.
when they went back to access these drawers at a later date they could not
access them.  They could select the drawers, but they would get a message that
the drawer was being used by another user.  The owner field for the drawer in
the status field would be blank.  Only one drawer was affected for each user.
They had full access to their main and other shared and private drawers.
Looking in the OAFC$SERVER.LOG file I noticed the following error message
being logged when they tried to access the drawers.


>Error: %MCC-E-IN_USE_ERROR, in use error  
>Message: CsiCacheFlushDrawerAccess; Error from mcc_mutex_try_lock


I stopped the file server, deleted the process from the system, and restarted
the file server.  this created a new file server process.  After doing this the
drawers seemed to be fine.  The two user could access their individual drawers
with out any problems.  Since then I have not been able to duplicate the 
problem.  Any ideas?


2.  When unprivileged users use the FC DRM IAD option to list drawers they
generate security violations on the system.  As well when a privileged user
uses this option, the user has full access to all drawers on the system.  
including privite and MAIN drawers of other users.  From reading note 444 
it seems that the system simply checks to see if the user has access to an 
individual drawers access.dat.  If the user does, it is listed, if not it is
not listed. 



>    GET #ACCESS_FILE = PARTITION.DIRECTORY[OA$CURDWR_LOCATION] "ACCESS.DAT"
>    CHECK_ACCESS ,#FILE,"R",#ACCESS_FLAG
>    .IF OA$STATUS AND #ACCESS_FLAG THEN .GOTO READ_ALLOWED



However a side effect of this is that it generates a security 
alarm for a file access failure if security monitering is enabled and the 
user does not have priviledge to access the ACCESS.DAT fileof the drawer 
it is testing..  This system has upwards of 300 ALL-IN-1 users.  Thats an 
awfull lot of security alarms!

Turning off security monitoring is NOT an option.  I have two questions.

	- Is there any way to prevent priviledged users from accessing 
	  drawers to which they have not been given access?

	- Is there any way to prevent these security alarms from being logged
	  when the user selected the IAD option?



regards,


Barry 

    Barry,
    
    I'm sure that problem 1 is discussed elsewhere in this conference
    though a quick search didn't find it - i'll post a pointer when I
    find it.
    
    Problem 2 is fixed in ALL-IN-1 v3.0-1 available from your friendly
    local CSC or even from SSB.
    
    Regards,
    
    Andrew.D.Wicks
           

    
    I THINK, that you can get aroudn teh security warnings by putting
    a node name in the SYSTEM field on the form. Note I am not 
    sure this will work. If you can get the FCS to do the access 
    checks for IAD, I believe you will get around the security 
    alarm since no access is attempted to ACCESS.DAT, we simply check
    if you could do it if you wanted. If you put the system name, I 
    believe that IOS will call the FCS to do the IAD, without the system
    name it does not use the FCS.
    
    As for restricting priv'd users from drawers. Sorry nope, by giving
    them privs you have given them access to the drawers. Someone in 
    an earlier note said something along the lines of if you can't 
    trust them take away teh priv's.
    
    --Bob
    

Have a look at NOTE 2165 ...

Joerg