Re: maybe problem in SECURITY_MODE in Shark.conf..?

Hi Geeta, Sebastian,

yes this is bug in Shark.conf and in StandardSecurityManager implementation. To have a workaround, you should define doubled properties in Shark.conf, ones using prefix:

    SecurityManagerClassName

and others using prefix

    StandardSecurityManager

Thanks,
Sasa.

  ----- Original Message ----- 
  From: [email protected] 
  To: [email protected] 
  Sent: Wednesday, June 22, 2005 4:20 PM
  Subject: [shark] maybe problem in SECURITY_MODE in Shark.conf..?



  Never mind my earlier message (I'm still looking into it..). After a night's sleep, here's what I find: 

  Problem 1. Shark.conf has notation for SecurityManagerClassName.SECURITY_MODE (default set to "NORMAL_SECURITY"). 
  However, StandardSecurityManager has in its configure method this check: 
  String sec_m=cus.getProperty("StandardSecurityManager.SECURITY_MODE","NORMAL_SECURITY"); 
  So no matter what you set SecurityManagerClassName.SECURITY_MODE to in Shark.conf, in StandardSecurityManager, security_mode will always be set to NORMAL_SECURITY (if you use shark's StandarSecurityManager) 

  Problem 2. In StandardSecurityManager, here's code for check_process_get_activities_in_state: 

  public void check_process_get_activities_in_state (SharkTransaction t,String procId,String userId,String procCreator) throws SecurityException { 
        if (SECURITY_MODE==SECURITY_MODE_NUM_ADMIN_SECURITY) { 
           if (!adminUsers.contains(userId)) { 
              throw new SecurityException("StandardSecurityManager -> ADMIN SECURITY RESTRICTION: Only admin users are allowed to ask for process activities that are in certain state!"); 
           } 
        } 
     } 

  As you can see, the exception is never going to be thrown (since by Problem 1 above) SECURITY_MODE==SECURITY_MODE_NUM_ADMIN_SECURITY will always be false. 

  This seems like maybe it's a bug..? 
  Geeta