Wait a sec. We are worried about an administrator that has access to
the console from seeing a password embedded an a configuration file?
The admin can deploy applications, which could easily just scan for
passwords in memory or on disk. Anyone with access to this console
is "root" for the geronimo instance.
-dain
On Nov 18, 2005, at 8:57 AM, Dain Sundstrom wrote:
If we are the ones copying over the plans, why not have the
deployment code for the module, simply remove passwords from the
file before copying it. Alternatively, we could choose to not copy
over the plan for connectors.
-dain
On Nov 17, 2005, at 11:30 PM, Aaron Mulder wrote:
Note that JSR-77 requires us to expose the J2EE DD through our module
beans, and it may make sense to provide a similar hook for the
Geronimo plan. That would make it easy to implement nicely in the
console, certainly.
However, I agree that it's important to be able to suppress showing
plans, particular for connectors where they're likely to have
passwords in them. Sure, you only see that if you got into the
console/MEJB/whatever to begin with, but still... I'm not sure what
to say about the default behavior. I thought this was such a cool
idea until I thought about the password issue, but if we make hiding
the plans the default, then it's not all that useful a feature. I'm
waffling.
Aaron
On 11/18/05, David Jencks <[EMAIL PROTECTED]> wrote:
On Nov 17, 2005, at 9:21 PM, Vamsavardhana Reddy wrote:
On 11/17/05, David Jencks <[EMAIL PROTECTED]> wrote:
On Nov 17, 2005, at 4:45 AM, Vamsavardhana Reddy wrote:
If deployment plans are inside the archive (ear, war, etc.)
they can
be obtained from config-store. If the deployment plan is
supplied as
an external file to the deployer and if the original file is not
available, the only way to get any information on the
configuration
is
from the Configuration GBeanData obtained from the kernel at
runtime
or from deserializing config.ser files under config-store. For
analyzing any problems after an application is deployed,
deployment
plans will certainly be helpful.
If you think this is really valuable information, I think a better
approach is to store the plan(s) in a known location in the
configuration so they may be retrieved directly.
I thought of this as an option because it will really simplify
a lot
of things, and I can avoid writing a configuration decompiler :o).
But, then will there be any instances where the user will not
want the
deployment plan to be stored in the server as is? Will "not want to
store the deployment plan in the config-store" be ever a users'
reason
for supplying deployment plan as an external file to the deployer?
Well, I think there will be few cases where the original deployment
plan will be unavailable from other sources, and I don't
particularly
like including it in the configuration. However, I don't think this
has much to do with the desirability of keeping the plan separate
from
the module you are deploying: I think this is always a good
idea. I do
think that some people will want to conceal their plan and if we do
provide a way to include it in the configuration this choice must be
optional.
thanks
david jencks
