[merlin] code security - ON or OFF

[Stephen McConnell <mc...@apache.org>]

I working through the code security implementation in the composition 
and activation packages and I have a couple of questions/comments 
related to the setting of the security manager:

1.  first off - I think the setting of the security manager should
     probably be moved to the repository package DefaultInitialContext
     class - this class is the entry point for bootstrapping merlin
     and creating the initial merlin classloaders

2.  second point - the decision to enable security is currently
     based on a true/false property which functions perfectly,
     however - there are usage problems:

     -  Take the Hello component - if I simply run the Hello build,
        the default behavior is that a merlin kernel is launched
        (via avalon-repository DefaultInitialContext).  The kernel
        grabs the default kernel configuration, sets security
        enabled to true.  DefaultBlock kicks in, security manager
        is assigned - everything proceeds except for two things:

         (a) proxy creation is not possible to to insufficient
             permission
         (b) jvm exit is not possible due to insufficient
             permission

     -  What I have been trying to figure out is how to detect if
        the assignment of the security manager will in effect
        invalidate the normal function of the container.

I.e. want I want figure out is a function:

     boolean isAssociationOfASecurityManagerPractical()
     {
         // some smart code that makes sure we will have
         // the necessary privs to function normally
     }

The important point here is that the kernel will be running in 
environments that we are not in control of - and in this respect we need 
to be adaptive and make sure we don't block an application because we 
have assigned the SecurityManager in an host that is running in default 
mode.

Any thoughts?

Cheers, Steve.

-- 

|------------------------------------------------|
| Magic by Merlin                                |
| Production by Avalon                           |
|                                                |
| http://avalon.apache.org/merlin                |
| http://dpml.net/merlin/distributions/latest    |
|------------------------------------------------|


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

Re: [merlin] code security - ON or OFF

[Niclas Hedhman <ni...@hedhman.org>]

On Wednesday 21 January 2004 19:31, Stephen McConnell wrote:

> 1.  first off - I think the setting of the security manager should
>      probably be moved to the repository package DefaultInitialContext
>      class - this class is the entry point for bootstrapping merlin
>      and creating the initial merlin classloaders

Possibly true. It is even debatable if it should be a container concern at 
all, or be set by the initial launcher.

> 2.  second point - the decision to enable security is currently
>      based on a true/false property which functions perfectly,
>      however - there are usage problems:

These usage problems are there because the implementation is not yet done, and 
I need to sort out the bugs. In doing so, I will need to address these 
problems.

> The important point here is that the kernel will be running in
> environments that we are not in control of - and in this respect we need
> to be adaptive and make sure we don't block an application because we
> have assigned the SecurityManager in an host that is running in default
> mode.

Good point, but it is likely that the 'outer container' (Tomcat or whatever) 
has established not only the security manager, but more importantly the 
policy for the Merlin container. In such case, we would need to handle the 
case where we are not allowed to further restrain the permssions of the 
thread (i.e. if we don't have createAccessControlContext (or what ever it is 
called) rights).

I'll be back with more reports about progress.

Niclas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org