You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by si...@insession.com on 2005/07/07 05:13:12 UTC
Invoking the deploy tool under a security manager and startup scripts
Resending this question as it was hidden in thread 'Re: Startup Scripts
discussion ( GERONIMO-693 )'
Should we be invoking the deploy tool in startup scripts with the
following (taken from GERONIMO-502)?
java -Djava.security.manager
-Djava.security.policy=var/security/deployer.policy -jar bin/deployer.jar
<standard> switches and parameters
If so, it appears that we would then want the izpack installation to
substitute the port numbers the user enters in the installer panels into
var/security/deployer.policy for ease of installation. Not sure if we need
to make changes to izpack (see link below) to support variable
substitution in policy files (AFAIK, policy files are supposed to be in
UTF8 encoding scheme, so the izpack VariableSubstitutor class may need to
be enhanced to have a TYPE_JAVA_POLICY that defaults to UTF8 encoding.
http://cvs.berlios.de/cgi-bin/viewcvs.cgi/izpack/izpack-src/src/lib/com/izforge/izpack/util/VariableSubstitutor.java?rev=1.4&content-type=text/vnd.viewcvs-markup
If not, why? Should we have a command line switch that turns the security
manager on/off?
Thanks,
John
This e-mail message and any attachments may contain confidential,
proprietary or non-public information. This information is intended
solely for the designated recipient(s). If an addressing or transmission
error has misdirected this e-mail, please notify the sender immediately
and destroy this e-mail. Any review, dissemination, use or reliance upon
this information by unintended recipients is prohibited. Any opinions
expressed in this e-mail are those of the author personally.
Re: Invoking the deploy tool under a security manager and startup
scripts
Posted by Gianny Damour <gi...@optusnet.com.au>.
On 8/07/2005 8:29 AM, Alan D. Cabrera wrote:
> sissonj@insession.com wrote, On 7/6/2005 8:13 PM:
>
>> Resending this question as it was hidden in thread 'Re: Startup
>> Scripts discussion ( GERONIMO-693 )'
>>
>> Should we be invoking the deploy tool in startup scripts with the
>> following (taken from GERONIMO-502)?
>>
>> java -Djava.security.manager
>> -Djava.security.policy=var/security/deployer.policy -jar
>> bin/deployer.jar <standard> switches and parameters
>>
>>
> I'm not sure that the Geronimo code works "properly" under the
> security manager. That is something that needs to be cleaned up.
> Also, I am certain that the "satellite" projects will need to be
> scrutinized as well.
Actually, its only for the deployer and not for the server. Anyway, this
will be ditched.
Thanks,
Gianny
>
>
> Regards,
> Alan
>
>
>
>
Re: Invoking the deploy tool under a security manager and startup
scripts
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
sissonj@insession.com wrote, On 7/6/2005 8:13 PM:
>Resending this question as it was hidden in thread 'Re: Startup Scripts
>discussion ( GERONIMO-693 )'
>
>Should we be invoking the deploy tool in startup scripts with the
>following (taken from GERONIMO-502)?
>
>java -Djava.security.manager
>-Djava.security.policy=var/security/deployer.policy -jar bin/deployer.jar
><standard> switches and parameters
>
>
I'm not sure that the Geronimo code works "properly" under the security
manager. That is something that needs to be cleaned up. Also, I am
certain that the "satellite" projects will need to be scrutinized as well.
Regards,
Alan
Re: Invoking the deploy tool under a security manager and startup
scripts
Posted by Gianny Damour <gi...@optusnet.com.au>.
I can easily implement that. At the same time, I propose to ditch
geronimo-classloader-server, which becomes dead code if we do no more
require remote class loading. I will ditch the module in 48h from now if
no one objects during this period.
Thanks,
Gianny
On 7/07/2005 11:02 PM, Aaron Mulder wrote:
> I believe a solution to the remote class loading problem is to
>wrap any deployment exceptions in such a way that you don't need the
>remote classes. For example, print the stack trace of a QL exception to a
>String, pop that in a field of a DeploymentException, and send the
>DeploymentException without a linked QL exception. Or better yet, forget
>the stack trace (or only print it on the server) and just print the actual
>error message on the client side (Can't deploy: your EJB QL is invalid:
>'...'"). That seems to make a lot more sense to me than allowing remote
>class loading just to print arbitrary exceptions.
>
>Aaron
>
>On Thu, 7 Jul 2005, Gianny Damour wrote:
>
>
>>One of the benefit is to allow for remote class loading of classes,
>>which cannot be loaded from the deployer classpath. For instance,
>>exceptions nested within DeploymentExceptions may not be defined by the
>>deployer classpath, e.g. org.tranql.ql.QueryException, which result in
>>ClassNotFoundException to be thrown on the deployer side.
>>
>>I don't think that we should enable remote class loading by default,
>>especially with the provided policy file. Perhaps that we could control
>>the installation of a security manager via a switch.
>>
>>Thanks,
>>Gianny
>>
>>
>>
>>>>John
>>>>
>>>>
>>>Jacek
>>>
>>>
>>>
>>>
>>
>>
>
>
>
Re: Invoking the deploy tool under a security manager and startup
scripts
Posted by Jeremy Boynes <jb...@apache.org>.
Aaron Mulder wrote:
> I believe a solution to the remote class loading problem is to
> wrap any deployment exceptions in such a way that you don't need the
> remote classes. For example, print the stack trace of a QL exception to a
> String, pop that in a field of a DeploymentException, and send the
> DeploymentException without a linked QL exception. Or better yet, forget
> the stack trace (or only print it on the server) and just print the actual
> error message on the client side (Can't deploy: your EJB QL is invalid:
> '...'"). That seems to make a lot more sense to me than allowing remote
> class loading just to print arbitrary exceptions.
>
Agreed.
I'd also agree that the stacktrace is of little value to the average
user and just logging the stacktrace on the server for "unusual"
problems would be enough.
--
Jeremy
Re: Invoking the deploy tool under a security manager and startup
scripts
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I believe a solution to the remote class loading problem is to
wrap any deployment exceptions in such a way that you don't need the
remote classes. For example, print the stack trace of a QL exception to a
String, pop that in a field of a DeploymentException, and send the
DeploymentException without a linked QL exception. Or better yet, forget
the stack trace (or only print it on the server) and just print the actual
error message on the client side (Can't deploy: your EJB QL is invalid:
'...'"). That seems to make a lot more sense to me than allowing remote
class loading just to print arbitrary exceptions.
Aaron
On Thu, 7 Jul 2005, Gianny Damour wrote:
> One of the benefit is to allow for remote class loading of classes,
> which cannot be loaded from the deployer classpath. For instance,
> exceptions nested within DeploymentExceptions may not be defined by the
> deployer classpath, e.g. org.tranql.ql.QueryException, which result in
> ClassNotFoundException to be thrown on the deployer side.
>
> I don't think that we should enable remote class loading by default,
> especially with the provided policy file. Perhaps that we could control
> the installation of a security manager via a switch.
>
> Thanks,
> Gianny
>
> >
> >> John
> >
> >
> > Jacek
> >
> >
>
>
Re: Invoking the deploy tool under a security manager and startup
scripts
Posted by Gianny Damour <gi...@optusnet.com.au>.
On 7/07/2005 9:07 PM, b Laskowski wrote:
> sissonj@insession.com wrote:
>
>> Should we be invoking the deploy tool in startup scripts with the
>> following (taken from GERONIMO-502)?
>>
>> java -Djava.security.manager
>> -Djava.security.policy=var/security/deployer.policy -jar
>> bin/deployer.jar <standard> switches and parameters
>
>
> Why? I wonder what the benefit would be of doing so? Please elaborate.
One of the benefit is to allow for remote class loading of classes,
which cannot be loaded from the deployer classpath. For instance,
exceptions nested within DeploymentExceptions may not be defined by the
deployer classpath, e.g. org.tranql.ql.QueryException, which result in
ClassNotFoundException to be thrown on the deployer side.
I don't think that we should enable remote class loading by default,
especially with the provided policy file. Perhaps that we could control
the installation of a security manager via a switch.
Thanks,
Gianny
>
>> John
>
>
> Jacek
>
>
Re: Invoking the deploy tool under a security manager and startup
scripts
Posted by Jacek Laskowski <jl...@apache.org>.
sissonj@insession.com wrote:
> Should we be invoking the deploy tool in startup scripts with the
> following (taken from GERONIMO-502)?
>
> java -Djava.security.manager
> -Djava.security.policy=var/security/deployer.policy -jar bin/deployer.jar
> <standard> switches and parameters
Why? I wonder what the benefit would be of doing so? Please elaborate.
> John
Jacek